Top-down testing is carried out from the top, head module of the program. However, there is no strict, correct procedure for testing the next module. The only rule that should be followed when choosing the next module is that there must be one of the modules called by the module that was previously tested.
To illustrate this strategy, consider the below Fig. The program shown on it consists of twelve modules A-L. Suppose that the module J contains read operations from external memory, and module I – write operations.
The first step is to test module A. To execute it, you need to create stub modules that replace modules B, C, and D. Unfortunately, people often misunderstand the functions performed by stub modules. So, at times you can hear that “the stub should only record a message that establishes:” the module has connected” or” it is enough for the stub to exist without doing any work at all”. In most cases, these statements are erroneous. When module A calls module B, A assumes that B does some work, i.e. module A receives the results of module B (for example, in the form of values of output variables).
Are you interested in improving software quality at an attractive price?? A great way to achieve this goal is to resort to outsourced testing as soon as your development project begins.
When module B simply returns control or generates an error message without passing certain meaningful results to module A, A does not work correctly not because of errors in the module itself, but because the stub module does not match it. Moreover, the result may be unsatisfactory if the response of the stub module does not change depending on the test conditions. For example, suppose you want to write a stub that replaces a square root program, a table-lookup program, or a program for reading the corresponding record. If the stub always returns the same recorded result instead of the specific value expected by the calling module during this call, the calling module will work incorrectly (for example, will be hung up) or produce an incorrect output value. Therefore, creating stub modules is not a trivial task.
When discussing the top-down approach, one more thing is often missed, namely, the format of presentation of tests in the program. In our example, the question how should the tests be passed to module A? The answer to this question is not entirely obvious, since the top module in a typical program itself does not receive input data and does not perform I / O operations. The upper module (in our case, module A) receives the data through one or more stubs.
Add Comment