Implementation of unit testing practice is based on the two key principles: creating an effective test suite and choosing the way in which modules are combined into a runtime program. The second principle is very important, since it specifies the format of writing unit tests, the types of tools used in testing, the order in which modules are coded and tested, the cost of test generation and the cost of debugging (i.e., localization and error correction). Now we are going to consider two approaches to combining modules: incremental and monolithic testing.
The question arises: what is better – to test each module separately, and, then, combine them into a runtime program, or to connect each test unit to a set of previously tested modules? The first approach is usually called the monolithic testing method or the “big impact” method used for testing and assembling the program; the second approach is known as an incremental testing or configuration. QA services are used to improve the quality of software apps while they are developed.
As an example, consider the program in the above Fig. Rectangles are the six program modules (subprograms or procedures). The lines show the control hierarchy: module A calls modules B, C and D, module B calls the module E, and so on. In the traditional monolithic approach, testing is performed as follows. First, the six modules included in the program are tested, at that each is tested in isolation from the others. Depending on conditions (batch processing or interactive mode) and the number of actors, the modules can be tested sequentially or in parallel. Then the modules can be assembled and combined into a single program (for example, by editing links).
To test any module, you need a special driver module and one or more stub modules. For example, if module B is tested, you first need to develop tests, and then write a small program that will pass input test data to the module B that are necessary for its execution (run the test for it). (For this purpose, debugging tools can also be used.) The driver should also show the programmer some information about the results of the operation of the module B. In addition, since the module B can call the module E, it is recommended to create a stub module which will receive the control when calling the module E. The stub module used instead of the module E during testing is also assigned the name “E”, and it must simulate the functions of this module. After completing testing of all six modules, they are assembled into a single program.
Comments are closed.
