This experience is based on the practice summary of two small and medium-sized projects (one 2000 Manday, one 1500 Manday) in the past two years, and I hope to discuss and make progress with you.
- Automated unit testing is the basis of continuous integration
- Depending on the actual situation of the project, different levels of detail can be selected, such as
- Only test the input and output of Good Scenario
- Test the input and output of "fine" and "simple" Flow
- Test each Service method (developing and maintaining these test cases will be a challenging job)
- The biggest challenge of automated unit testing is the maintenance and understanding of existing use cases (easy to consume) "How to deliver the right software with instantiated requirements" P15
- Focus on long-term payoffs
- Although unit testing is strongly recommended, do not do unit testing, small projects You can also do a good job of quality
Unit
testing In the author's 10-year programming career, this is the part that the author programmer himself is most interested in and has not done yet. Including hundreds of Manday's small projects, tens of thousands of Manday's large projects, and hundreds of people's cooperation in large products, none of them are satisfactory.
But the author programmer feels that this part should be achievable, and the following is a detailed analysis.
The following are some of the more typical difficulties, we will analyze them one by one.
Q1, if you have time to write unit tests, it is better to save time to develop new functions.
Imagine how much pressure programmers with such thoughts are facing. I am chased by clients and bosses every day, without a moment of respite. But think about it from another angle, such customers are also miserable, yes, customers are also miserable. Under his pursuit, the programmers made the functions he wanted "on time". However, can he sleep soundly with such a system in hand? Isn't he worried about being woken up by his boss in the middle of the night and scolded? Because the system "again" has a problem. It's time for programmers and customers to pay off technical debt together.
quote
Technical debt was first coined by Ward Cunningham to explain to non-technical stakeholders why they were doing what we now call "refactoring." Steve McConnell's explanation of technical debt is that technical debt is a short-term expedient, but in the long-term the same job will cost a lot more than current dues. Jean-Louis Letouzey's interpretation of technical debt is: the sum of the cost of remediation for inappropriate practices.
So why is not writing unit tests a technical debt? The author programmer wants to use the interview method to analyze this problem.
Author programmer: If you don't write unit tests, how to ensure quality?
Programmer: Manual testing can also achieve the same effect.
Author programmer: OK, agree.
Author programmer: Assuming that it takes 10 days to complete a complete function (function A), do you need to test the code you wrote that day on the first day?
Programmer: Of course.
Author Programmer: On the fifth day, will you test the code you wrote on the first day?
Programmer: Maybe.
Author programmer: On the tenth day, will you test the code you wrote on the first day?
Programmer: There should be a regression test.
Author programmer: On the tenth day, will you test the code you wrote on the first day in detail?
Programmer: It should be.
Author programmer: You are really a good programmer, praise!
Author programmer: After a year, if you change the code of function B, but it "may" affect function A, will you test function A?
Programmer: Of course we have to test it.
Author programmer: Will function A be fully tested?
Programmer: Yes.
Author programmer: You are really a role model in the world of programmers, thank you again!
Author programmer: When testing, does it take more time to change the code, or more time to test?
Programmer: The time to test is much more than the time to modify the code.
Author Programmer: Two years later, the development team of this big project was disbanded, and you were responsible for the maintenance of the project. At this time, if you change function C, but it may affect function D, the worst thing is that function D was not developed by you, what would you do?
Programmer: I will do Impact Analysis, Regression Test, and detailed testing.
The question is here, this lovely and respectable programmer will have two directions of development. Either become a saint, or become a martyr. Which do you think is more likely?
At this time, the cost of maintaining the project will be very high. This is the technical debt that comes with development.
If the goal of the project is "completion" rather than "high quality", even when users themselves don't care about quality, TDD and CMM are all gimmicks, and eating and drinking is the core of the methodology.
Note: Unit testing is not the only reason for difficult maintenance, but it is a very important one.
Here is an introduction to the quality iron triangle, which is scope, time and cost. Changes in any one of the three will have an impact on the other two. The goal of project management is to balance the relationship between the three to achieve the best results. Therefore, if you want to improve the quality, you can only control . From the author's personal experience, this is the method with the least impact on the project. As for the control method, it has been described in detail in the requirements article ( http://www.iteye.com/topic/1134230 ), so it will not be redundant here.
Q2, the requirements are constantly changing, and the code is constantly changing. It is not a waste of time to maintain those unit tests.
For this problem, we still use the interview method to analyze.
Author Programmer: If the requirements keep changing, how do you ensure quality?
Programmer: I will do a detailed test of the modified places.
Author Programmer: What about those places that have not been changed, but may be affected?
Programmer: I will also do detailed regression testing.
Author programmer: When testing, does it take more time to change the code, or more time to test?
Programmer: The time to test is much more than the time to modify the code.
Author Programmer: Is there anything missing? How is it guaranteed?
Programmer: . . . . . .
For a complex system, if there is no good test case to support it, a lot of time will be spent on analysis and testing, and the proportion of development time will be less and less.
(This picture is borrowed from Design Debit's article)
Q3, if you write unit tests well, the code to be tested is more than the code of the system, and you really can't afford such a cost.
For this problem, from a pragmatic point of view , The author programmer thinks that the law of 28 , and it is enough to test 80% of the cases when using 20%. Of course, this depends on the specific system. The slightest mistake is a 100% failure for the space shuttle. However, it is still applicable to the large-scale banking projects that the author programmers are engaged in, because it has a certain mechanism to make up for or control the errors of a certain system without causing losses to the bank.
quote
The 28th Law, also known as Paredo's Law, was invented by Italian economist Paredo in the late 19th and early 20th centuries. He believes that in any group of things, the most important only accounts for a small part, about 20%, and the remaining 80%, although the majority, is secondary, so it is also called the rule of 28.
To answer this question, the author programmer believes that different levels of detail can be selected according to the actual situation of the project, such as
- Only test the input and output of Good Scenario. This is the next best choice when the project time is very limited, and you don't want to give up the quality assurance completely, because this option takes very limited time, but it ensures the normal operation of the most basic functions of the system. Equivalent to smoke testing, usability testing.
- Test the input and output of "fine" and "simple" Flow. This is the second of the 28 laws. It can test the main functions of the system without introducing too many test cases, which will lead to the cost pressure of the system and the complexity of case maintenance. If this is done, it should not be a problem to ensure that the programmers sleep peacefully. So, this should be the goal of most projects.
- Test each Service method (developing and maintaining these test cases will be a challenging job). This rule is relatively simple, but very difficult to implement. The difficulty is not because there are so many test cases, but how to maintain and manage these cases.
Q4, do those simple codes really need to be tested?
For example , compared with the above problem, the author programmer thinks that CRUD operation is a very real problem. It is also a question of the benevolent seeing the benevolent and the wise seeing the wisdom. Or, to put it another way, it's not a problem at all. The problem is that we decide which level of detail to choose for the test.
Conclusion
There is no unit test, continuous integration will be on paper, and there is no automated unit test. What do you do with the Build system every day, just to see if the code can be compiled and passed?
Without testing, there is no courage and confidence, only fear and anxiety. Write tests until fear turns to boredom, Philip says.
Without unit testing, it's like a blind man walking a blind road. Maybe some "kind-hearted" programmer has already paved a "good road" for you.
Therefore, if the client or the boss asks the majority of programmers to write unit tests, it is not an excessive requirement. They just want to sleep peacefully. It is not easy for everyone, so let their dreams come true.
Questions to think about
In an agile team, how can the test team continue to function? Obviously, a lot of manual testing can no longer meet the needs of fast delivery.
Three recommended books
- TDD "Test Driven Development" (US) by Kent Beck, translated by Bai Yunpeng, Machinery Industry Press
- BDD "How to Deliver the Right Software by Instance Requirements Team" [Serbia] by Gojko Adzic, People's Posts and Telecommunications Publishing House
- ATDD "Acceptance Test Driven Development" [German] Markus Gartner, People's Posts and Telecommunications Press
How to prepare test data
If any programmers are worried about preparing test data for unit testing, I hope the green gadgets below can help you.
Data Driven Testing (3) - Using Tools http://www.iteye.com/topic/1133877