Test stubs and test driven writing methods in software testing

Then you still don't have a clear understanding of these two concepts.

The so-called test stub is called by the module method you are responsible for testing, so you need to imitate them to make a return value (fake, but as designed).

The so-called driver test means that you are responsible for testing the module method in the middle, there is no main() entry, how to compile, how to start? You need to write a method with main() to call your module method, which is the driver test.

public class ddd

test driver

public static void main(string args) {

ddd d = new ddd();

my module

public int add()

int output= ;

my module: return value is "+output+"");

return output;

stub1public int stub1()

int output=3;

stub 1 : return value is "+output+"");

return output;

stub2public int stub2()

int output=7;

stub 2 : return value is "+output+"");

return output;

I have seen the problem of piling, but I forgot it, I remember that I saw it in the knowledge library of Zezhong Software two days ago.

Test piles are used for top-down testing. It swapped itself for low-level modules. It looks and behaves like a low-level module for the high-level ** to be tested.

The test drive is the opposite of the test and spring pile, which is used for bottom-up testing. It is a place to replace high-level software and run tests of low-level modules more efficiently**.

From low to up, you can understand that the first assembly of the strip and then the assembly of the wheel, and finally the assembly of the car, now the strip is made, but the wheel frame has not come out, we have to test the strip, for example, test the thread of the strip is good, etc., then we need to build a wheel according to the detailed design of the screw interface (that is, the driver written in the unit test), so that we can simulate the strip installed on the wheel, according to the thread on the wheel buckle interface to judge whether the thread of the strip is normal. This is how drivers work in unit testing. Conversely, it is the same, from the top down is the existing wheel, then of course it is a forged strip, this strip is a pile, therefore, looking at the problem, it is obvious that there is only a strip without a wheel, so to simulate the wheel (that is, the driver), of course, choose A.

Hope it helps.

Obviously, it's not a b-pile program, it's a driver.

The bottom-up method starts the assembly and testing from the lowest module in the program module structure, that is, for a certain module under test, its submodules have been assembled and tested in advance, and there is no need to write a stake program.

A driver is a higher-level module that simulates the module under test. For the testing of the submodules mentioned above, you need to write drivers.

The stake program is the module that simulates the module under test, that is, the next level module. Because it's bottom-up now, there's no need to write about it.

Test-driven development (TDD) refers to staggered testing and development, which is a program development method and a part of extreme programming. The steps are as follows:

1. Identify the required function increments.

2. Write a test for this feature and implement it as an automated test3. Run this test, and all other tests that have been implemented4. Implement this feature, and re-run this test.

5. Once all the tests are successful, move on to the next function as described in the book Software Engineering, Chapter 8, Section 2.

My understanding is that the test of the function is implemented first, then the function is implemented, and finally the implemented function is tested with the test that was implemented first.

It is recommended that the landlord take a look at the classic book of software engineering.

Drive BAI

When the function under test cannot be run directly, you need a special function to drive its operation, such as the main function, or other functions that can run this function so that you can test it.

When testing the upper function, because the tested function needs to call some functions of the relative bottom, when the underlying function is more complex, you can consider making a simple called function to replace the original underlying function, provided that it will not affect the ** you want to test too much. This is the pile.

In short, the mission of the driver function module is to call the module under test according to the design of the test case, and determine whether the return value of the module under test matches the expected result of the test case.

This should be a three-tier structure.

Bottom piling, middle drive, upper behavior simulation.