Decision functions

The key concept behind the Test framework is a decision function. A decision function is the code you write that determines if the code you are testing is doing what you expect. A decision function is usually part of the Test member function, but you can also write decision functions as individual member functions. For example, if you have an object that returns the value sent to it, a decision function might compare the value you send with the value the object returns to make sure the two are equal.

The Test framework allows you to organize decision functions into tests with standard interfaces that can be run repeatedly to create regression test suites. The test suites can be run automatically and do not require special knowledge about the code being tested. The tests return information about the success or failure of the decision functions.

The most important part of using the Test framework is designing a test, or group of tests, that properly exercises your code.

Before you use the Test framework to organize your tests, decide what operations you can use for each class to test the public, protected, and private interfaces. For example, you might find that for an instance of TSampleObject, which contains SetString and GetString functions, you can perform several different operations to test the functions. Each operation might take arguments, such as different strings. The arguments reflect special cases to ensure that the functions properly handle those cases.

Cast each operation as a decision: Does the operation work correctly? The outcome of the test condition must be True or False, indicating the success of the associated operation. Here is an example of a decision function that compares the value for a variable with the length:

      if (maxlength != fExpectedLength) 
          SetSuccess(false);

In this example, if the two values do not match, you pass a value of False to SetSuccess, which means that the test failed.

You can have as many conditions as you want in the decision function, but the Test framework allows a single pass or fail result for each decision function. If a single decision function failure could have multiple causes, the scope of your function is too large.

When you start writing your tests, you might create a class for each test to keep your decision functions simple. As you write more tests, you can identify patterns and groupings of tests that make sense. For example, you might use the following process to create tests for your class:

Write a test class that simply displays a message. This is a good starting point and makes it easy to build your test program and check it.

Write a base test class that you can use to define common functions and data. As you write more tests, you might find that you keep using the same functions or data in your tests. By defining a base class initially, you have a place to maintain common information as you develop your tests.
Derive your tests from the base test class and override the necessary member functions for each test you write.

By starting with a base test class and deriving your tests from that class, you have an organized and easily maintainable structure for your tests.

[Contents] [Previous] [Next]

Click the icon to mail questions or corrections about this material to Taligent personnel.

Generated with WebMaker