TestOrganization

A test case is a unit of test in much the same way that a function is a unit of code. It may contain just the object being tested as well as some statements and assertions needed to perform the test, or it may be divided into a number of sub-tests (a.k.a test scenarios) containing the same sort of things and executed in sequence.

A test case always starts with the test object in a given state and environment. It then applies a defined set of inputs and measures a defined set of outputs in order to validate that a particular part of the specification has been implemented without revealing any bugs. When a test case ends it must leave the product and its environment in the same state as when the test case started. The execution of one test case should not impact on the execution of another; tests must be isolated.

Test fixtures are objects that may be employed within test cases to help set-up the test environment and initial state of the test object. A test framework or test tool can provide facilities that simplify the task of creating and recovering test fixtures, as well as making it easier to write and run the test cases themselves. The test case may be compiled into a test program or alternatively contained within a test script to be interpreted by a particular test tool at runtime. A collection of related test cases is called a test suite which is the entity of execution for your tests; you run a test suite.

Your tests will usually be executed in a test environment which is separate to that of the production (or development) system. It is essential that when the product finally operates in the production environment, doing real-world work for the business, you can be confident that no new bugs will appear. For this reason the environments should be as similar as possible. Test fixtures are often used in a test environment to simulate features of the production environment that cannot easily be duplicated.

It is as important to control the building of your tests into a test suite as it is to control the construction of your product from its source files. Typically, you will automate this process using a tool like Make so that both tasks are done together and are consistent with each other. However, you must ensure that the tests and the product are clearly separated so that the product can eventually be released into the production environment without any of the excess baggage required by the test environment. You should configure your build process so you can perform either a test build or a production build depending upon your desired target environment.

In the early stages of testing you may change the settings for your test build (debug) to generate a program that is very different to that created by the production build (release), but in the later stages of testing you should try to ensure that both types of build produce essentially the same executable code. You may find it useful to create a number of different configurations for your build procedure as your testing progresses to help organize your testing. Good test organisation is the key to having efficient testing throughout the life of your product.

Extracted from an article by BillStott