Test-driven development (TDD)

Test driven development (TDD) may have been used by many people. It was born in the 1990s S (it seems to be a long time ago, but it is actually okay, around 1996 ), it is part of extreme programming.

 

Some may ask why such an "old" thing will be introduced today. Well, the well-known answer is that the ancient waterfall model is still in use, of course we can talk about this relatively "modern. Of course this is not the case. Over the past few days, the leaders thought that the product quality had to be improved, analyzed the reasons, and thought that TDD should be useful. So, we need to start this journey ......

 

Next I will introduce the specific problems we encountered and how to implement test-driven development. (Of course, it cannot be said if it is unsuccessful, but everything always needs a start !)

 

As mentioned in previous articles, we use agile methods, mainly scrum, to manage the entire process of software development in our company. From requirement acquisition to design, development, and testing, we all useTechexcel devsuiteIn theory, there should be no problems with the management of the system. In each iteration cycle, after a function is developed, the test can be put into testing and the problem can be solved in a timely manner. However, the theory always needs to be tested. After a period of operation in this model, many problems still exist, but the main problem is that there are always many bugs, not to mention the issue of development capability, but the unexpected issue of many developers involved in bugs. Developers always think that they have achieved a good design intent, so the product is perfect, however, testers always find a lot of problems.

 

In this way, a lot of bugs will inevitably produce several results. One is that the developer's capabilities are under suspicion, and the other is to fix bugs, which takes a lot of time, the last one is, of course, the product quality is always low.

 

In fact, developers are also quite innocent, and a functional test point cannot be written in all aspects of the design document, and many test points may not be common operations by testers, but now the problem has come out, there is always a solution to this problem. If you think about it, the leaders will think about the concept of test-driven development. Of course, the concept of test-driven development in our company is a little different from its real concept, the standard concept should be as follows:

 

The basic idea of test-driven development is to write the test code before developing the function code, and then write only the functional code that passes the test to drive the entire development process. This helps you write concise, usable, and high-quality code with high flexibility and robustness. It can quickly respond to changes and accelerate the development process.

The basic process of test-driven development is as follows:

1. Quickly add a test

2. run all the tests (sometimes only one or some of them need to be run) and discover that the newly added tests cannot pass

3. Make some minor changes to make the test program run as soon as possible. Therefore, some unreasonable methods can be used in the program.

4. Run all tests and pass all

5. refactor the code to eliminate repeated designs and optimize the design structure.

In short, it is not running, runable, or restructured-this is the slogan of test-driven development.

 

For us, because we have our own actual situation, we adopt this idea. However, to implement it in our own way, the idea of test-driven development is"The purpose of the test is to let you know when the test is completed. If you are smart, you should first write the test so that you can know if you have completed it in time. Otherwise, you often don't know which functions are actually completed, and how far is it from the expected goal."

 

Based on this idea, we have made some changes to the development process (the original development process is not described much. For details, see my previous article ),

 

Step 1:For a designed function, the tester needs to write test cases first. Although the product has not yet been developed, the tester also knows what a function is like according to the design documents, therefore, according to the standard test points and some of their own ideas, we should first write the test cases, because they are the test cases written by the testers themselves, so basically during the real test, these test points are tested, in fact, this function is almost tested:

 

Test Case 1:

Test Point 1 :......Under development

Test Point 2 :......Under development

Test Point 3 :......Under development

......

 

Step 2:Then, the developer starts to normally develop functions according to the design documents. However, when he develops the functions, he needs to check the test points, if he verifies that these test points have been implemented in the product, he needs to change the test status to"Development completed", If all the test points of a function are verified and passed here, this function has been completed for this development, next, you can perform other functions or repair problems discovered by testers.

 

Test Case 1:

Test Point 1 :......Development completed

Test Point 2 :......Complete 90%

Test Point 3 :......Development completed

......

 

Step 3:Next, since the function has been completed in development, the tester will check whether the developer has completed these test points. If the test points are confirmed to pass, the test point status will be set to"Test passed".

 

Test Case 1:

Test Point 1 :......Test passed

Test Point 2 :......Test passed

Test Point 3 :......Test failed

......

 

However, in many cases, testing is not done after a function is developed, but is being developed. If a function needs to be completed in a few days, testers perform partial tests every day. To ensure that each function can be developed and tested in a timely manner, developers also need to update the status of completed test points in real time, because we generate a build every day, as long as a test point is completed, the build will soon be tested, and the status will be updated as soon as it is completed, which will help the tester to check and feedback in a timely manner.

 

In addition, during the testing process and even during the development process, we often encounter two problems: one is the sudden change in the function design, and the other is the tester's opinion that the test points should be modified or increased or decreased, these are very likely to have a great impact on the development process, so we need to promptly notify and adjust these things.

 

This is the process of test-driven development with the characteristics of our company. In fact, a single sentence is like "let developers develop a product with the eyes of testers". At present, we are stillDevsuiteThe necessary process for configuration in the system (many developers and testers sometimes handle and feedback many things because they are too busy, so there is still a need for systematic constraints ), it is estimated that the configuration can be completed in the past few days. I personally think it will be very challenging to implement the process at the beginning, because the process requires the development, testing, and even the close cooperation of designers, any small delay may cause a chain problem in the subsequent process. For example, if a developer does not go to the test point in time or update the test point status in time, the tester fails to perform the test in time, when testing, developers may be busy with other features without delaying the bug fixing of the previous feature. In the future, fixing bugs will cause unpredictable damage to the product ......

 

Of course, in theory, the light is not far away, but how can we see the rainbow without any storms? We have experienced a lot of hardships from waterfall to agility, however, I believe that we can still see the rainbow. In the future, we will update the details after the implementation is successful.

 

 

(Full text)