Pile module and drive module

Many people may be confused about the concepts of the pile module and the drive module. The following describes these two concepts:
Pile module: Before the integration test, we need to prepare some "substitute" modules for the tested modules to simulate the functions of their lower-level modules to replace the interfaces of the tested modules, accept or transmit data from the tested modules. These fake modules are called the pile modules of the tested modules.
Driver Module: In most cases, it is called a "main program". It receives test data and passes the data to the tested module.
The pile module is used to replace the measured sub-module. It cannot be empty, but it does not need to implement all the functions of the sub-module, as long as it is implemented in part;
A driver module is used to call a sub-module instead of the main module.
To put it simply, the upper layer of the module is the driver module, which calls the tested module. The lower layer of the tested module is the pile module, which is called by the tested module.

Assume that the project team has assigned seven members to implement a module. You are responsible for Module B. You are excellent. The first one completes coding. Now you need to perform unit testing. First, analyze the structure diagram:

1. Because Module B is not the top-level module, it must not contain the main function (module A contains the main function), so it cannot run independently.
2. Module B calls Module D and module E. At present, neither Module D nor module E is well developed, so it is impossible to compile Module B through the compiler.
So how can we test module B? You need:
1. Write two modules, SD and Se, respectively, to replace Module D and module E (the function name, return value, and transmitted parameters are the same), so that Module B can be compiled. The SD module and the se module are the pile module.
2. Write a module da to replace module A, which contains the main function. You can call Module B in the main function to run Module B. The DA module is the driver module.
Knowledge point:
In addition to making the program compile, the mission of the module also needs to simulate the various possible return values of the replaced module (when to return the value depends on the test case ).
The mission of the driver module is to call the tested module according to the design of the test case, and determine whether the returned values of the tested module are consistent with the expected results of the test case.

 

The driver module calls the tested object, and the pile is the virtual block called by the tested object.

Virtual blocks are also a module written by testers.

The driver module is a simulation block written to drive the tested module, and the pile module is equivalent to the virtual block to be called by the tested module.

The driver module mainly implements the following tasks:

1. Accept test input;

2. Judge the input;

3. Pass the input to the tested unit to drive the execution of the tested unit;

4. Accept the execution results of the units under test and judge the results;

5. Use the judgment result as the execution result of the case to output the test report.

The language in which the Unit to be tested is written as the driver.

All in all, writing drivers and piles do not require too deep programming knowledge. If there is a template or framework as a reference, it will almost become a physical activity.

A simple example:

/* Tested program */INT fun (INT in) {If (in> = 0) {return 1 ;}else {return-1 ;}}

When you write extended commands through TCL, the driver for the tested function is as follows:

/* User-defined user commands used to drive the tested functions */

Int ex_testfun (clientdata, tcl_interp * interp, int argc, char * argv []) {int I; int ret, iexceptedret; // open the file * Out in the test result record; out = fopen ("D: \ result.txt", "A"); // Step 1: Check whether the number of user input parameters is correct if (3! = Argc) {fputs ("parameters error", out); fflush (out); Return tcl_error;} // Step 2: Obtain the user input parameter if (tcl_ OK! = Tcl_getint (interp, argv [1], & I) {return tcl_error;} If (tcl_ OK! = Tcl_getint (interp, argv [2], & iexceptedret) {return tcl_error;} // Step 3: Pass the parameter to the tested function ret = fun (I ); // Step 4: Compare the execution result of the function under test with the expected result of the input, and output the result to the test report as the execution result of the test case. If (Ret! = Iexceptedret) {fputs ("test fail", out); fflush (out);} else {fputs ("test success", out); fflush (out );} return tcl_ OK ;}

From: http://lsshappy007.blog.163.com/blog/static/3582025120108953750255/