#include <TestCase.h>
Inheritance diagram for TestCase:
A test case is a self-contained, and usually small test, that can either fail or succeed. The class encapsulating a test case is completely responsible for running the test from the set-up of the test conditions to the shut-down of the test and for reporting its outcome. A test case class is however "passive" in the sense that it has the capabilities to initiate, perform and terminate a test but these capabilities must be controlled by some external entity.
This class declares, and defines trivial default implementations for, four services. The test set-up service set up the conditions for the performance of the test case. The test execution service causes the test case to be executed. This service should only be called after the test set-up service was called. The test shut-down service performs any shut-down actions that may be required at the end of the test case. It should always be called at the end of a test case. The test reporting service reports the outcome of the test. The outcome of the test is made up of a true/false flag (the test outcome)and an explanatory message that contains additional information about its outcome (the test message).
This class defines two attributes for test cases. The test case ID is an integer acting as a numerical identifier of the test case. The test case name is a string that represent the name of the test case.
This class is abstract because the test execution service must be defined by subclasses representing concrete test cases. Default implementations are instead provided for the test set up and shut down services.
A pseudo-code example of how a test case could be run is as follows:
testCase.setUpTestCase(); testCase.runTestCase(); testCase.shutDownTestCase(); bool outcome = testCase.getTestOutcome(); char* testMessage = testCase.getTestMessage();IMPORTANT NOTICE: the framework classes are designed to prevent class instances from ever being destroyed (this applies both to explicit object deletion and to implicit deletion when an object variable goes out of scope). This presents a problem for the implementation of test cases since each test case should have its own set of variables in order to preserve the mutual independence of test cases. The solution adopted here is that each test case creates the class variables it needs dynamically on the heap but does not destry them when it terminates. This means that execution of a test case introduces a memory leak. The size of the memory leak should not cause any problems in a desktop environment.
Definition at line 72 of file TestCase.h.
Public Member Functions | |
TestCase (int testId, char *testName) | |
Constructor defining the test case ID and the test case name. | |
virtual bool | setUpTestCase (void) |
This method implements the test set up service. | |
virtual void | runTestCase (void)=0 |
This method implements the test execution service. | |
virtual bool | shutDownTestCase (void) |
This method implements the test shut down service. | |
char * | getTestName (void) const |
Return the test name. | |
bool | getTestOutcome (void) const |
Return the test outcome. | |
char * | getTestMessage (void) const |
Return the test message. | |
Protected Member Functions | |
void | setTestResult (bool outcome, char *testMessage) |
Method intended to be called by concrete test cases to set the test outcome flag and the test message. | |
bool | isNonNominalCheckAllowed (void) const |
Return true if non-nominal behaviour can be checked. |
|
Constructor defining the test case ID and the test case name.
Definition at line 16 of file TestCase.cpp. |
|
Return the test message. The test message can be an empty string (e.g. " ") but should never be the null string.
Definition at line 65 of file TestCase.cpp. |
|
Return the test name.
Definition at line 57 of file TestCase.cpp. |
|
Return the test outcome.
Definition at line 61 of file TestCase.cpp. |
|
Return true if non-nominal behaviour can be checked.
Some test cases may want to check the behaviour of the class under test under non-nominal conditions. In general, this should only be done if violation of an assertion check does not lead to a termination of the application. This is because the non-nominal situation might be caught by an assertion check which might lead to a premature termination of the test. This method returns true if violation of an assertion check does not lead to termination of the application. The method is implemented in terms of the pre-processor symbols NDEBUG and USE_SYSTEM_ASSERT defined in the include file
Definition at line 41 of file TestCase.cpp. |
|
Method intended to be called by concrete test cases to set the test outcome flag and the test message. This method should only be called once in a given test case. Attempts to call it more than once will result in an error message being stored in the test message and in the test outcome flag having an undefined value.
Definition at line 25 of file TestCase.cpp. |
|
This method implements the test set up service. This class provides a default implementation that always returns "set up was successful".
Reimplemented in TestCaseGenericSetUp, TestCasePUSFull, TestCaseWithEvtCheck, and TestCaseWithFactories. Definition at line 53 of file TestCase.cpp. |
|
This method implements the test shut down service. This class provides a default implementation that always returns "shut down was successful".
Reimplemented in TestCaseGenericSetUp, TestCasePUSFull, and TestCaseWithFactories. Definition at line 49 of file TestCase.cpp. |