Shulou(Shulou.com)06/03 Report--

Most of the time, many companies are in charge of the product, and the development is later, and the status of testing is relatively low, but is this really the case? a mature project should be led by testers in the progress of a mature project. Testing is the only position that enters the project first and confirms the completion of the project finally, so this article is to help you correct this mistake.

So are you testing ready to "hijack products to facilitate development"?

First, reflect the real needs

There is a difference between writing tests first and writing tests later.

Speak before you write the test. According to a lot of experience, when writing product implementation code directly, you need to consider the requirements, as well as the details of the implementation, what algorithm and syntax to use. Back and forth between requirements and considerations and implementation details, it is easy to cause negligence on one side, omitting some requirements, and even flaws in implementation.

Some people will say that I can pass the post-writing test to make sure. The first experience is that many people will not supplement testing after the implementation is complete, because there is more work and requirements to implement. The second is that it is easy for the developer to test his existing implementation in the post-test, rather than the requirement itself, and it is easy to miss some boundary checks and so on. During the test, the existing implementation details will be preconceived in mind, even if there are problems or loopholes in the implementation, it is difficult to test in the post-test. I have read a lot of interviewer's test code, which is obviously supplementary, because some obvious questions have not been tested, and even the logic that has been implemented has only been partially tested. And these interviewers all admit.

As a result, once the code is checked in and the integration begins, the problem is exposed, and the supplementary testing does not play a role in ensuring the requirements of the code, and the developer cannot do so without the help of debugging tools. step through every line of the implementation code to find the cause of the problem.

Besides, write the test first. According to the TDD process, first write the failed test, then write the implementation code that happens to make the test successful, finally refactoring, and so on. The advantage of this is that every time you write a test, you are trying to define the shelf of the implementation code with your own understanding of the problems and requirements. Define what the implementation code will look like in the future from different perspectives of testing, scope, boundaries, size, functionality, and so on. Test after test, using the TDD process, the implementation code happens to be no more or less, just to drive the implementation code to solve this requirement and problem.

The point here is that writing tests first allows developers to focus on understanding and implementing requirements, rather than getting caught up in implementation details in the first place and doing both at the same time. The test code written first, as a by-product, can be used as a strong guarantee for verification requirements.

Second, the design is in it

The advantage of writing tests first for design is to define new classes before writing tests, and to define the relationship between classes, that is, how classes interact with each other, how each class exposes its own interface, and the reference relationship between classes. At this time, the test code will force developers to seriously consider how to decompose the coupling relationship between classes, so that the resulting implementation code is easier to make use of IoC and DIP patterns to achieve interface-oriented programming.

The advantage of implementing the code in this way is that the code is highly testable, and when adding more test code and new classes, it also relies on the testability brought by the interface-oriented and dependency inversion of the existing classes. to achieve the interface-oriented and testability of the new implementation code, so as to enter a virtuous circle. This benefits a lot from the overall code and design. In other words, test is design.

Looking back at the situation of writing tests after writing, because from the beginning, developers focus on the details of implementation and the reciprocation of functional requirements, and it is easy to neglect code design, class relationships and definitions, and the result may be tight coupling. poor testability.

III. Enhanced information

In my opinion, the biggest problem with software development cycle and software delivery is the operation and maintenance phase after delivery, which is the period when software delivers value continuously. The maintainability of the software highlights the value at this stage. After software delivery, including during the software development cycle, it is inevitable that developers gradually add new functional code or fix some known defects according to new requirements.

A lot of experience shows that when developers add some new code into the system according to the requirements, or try to fix existing defects, it is easy to lead to existing functional errors, that is, the newly introduced code breaks the logic of the existing code. leading to regression problems. Because of the poor testability of the software system, it is impossible to do fast, frequent and automatic regression testing, so the maintainability is naturally very poor.

As one of the by-products of TDD, the test code that can be run automatically quickly and frequently can give developers enough confidence when they introduce new code. Every time they add a little new code, a method and a class, they have frequently run the relevant test code to ensure that the newly introduced code will not break the existing functions.

In continuous integration, these test codes can help verify that each check-in code does not break existing functionality. This is why it is repeatedly mentioned in ReFactor that you have to run all the test code after each small step of refactoring.

IV. Granularity and schedule

According to the principle of TDD, writing tests first allows developers to focus on only a small part of the functional requirements at the same time, divide the functional requirements into a certain granularity, express such requirements with test code, let tests pass with implementation code, achieve such requirements, and then refactoring.

The advantage of this is that the developer's own attention and focus do not have to hesitate between the small demand points in the entire functional requirements, focus on solving a single small problem at a time, and solve one problem to the next. While ensuring the implementation of small granularity, the progress can be interrupted at any time, but what has been interrupted at the same time is complete and runnable, at least part of the implementation code of the requirements has been realized.

The price of writing tests is that the first implementation code is likely to contain design problems or even defects, and before the perfect test code is completed (in fact, this is impossible), what can be delivered is that there may be serious defects. Even misinterpreted functional requirements of the implementation code.

The benefit given to you today is the "Standard Edition Test requirements document" document for listed companies.

Friends who need it can leave a message in the comments.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.