Joint debugging pain points

At the recent website, I often heard developers say that a Story has been developed, waiting for joint debugging, and then there will be no more. When the joint debugging time is near, developers will wait and a day passes quickly. When the time is too far, developers will get the new story and wait until the development of the other end is complete, several days have passed. I always think there is something wrong with it, but I cannot tell it. I went to QCon last week to listen to Mr. Han's sharing and suddenly found that such joint debugging was also available in the previous team. However, our solutions are different, so the problem is not so prominent.

The cause of the problem is very simple. In today's software development, as the complexity of the system increases, module splitting is also common, and it is difficult to form a team for end-to-end delivery without any external dependencies. A typical scenario is that module A is developed by A team 1, and Module B is developed by Team 2. At this time, after the function development of Team A is completed, it must be associated with the corresponding function developed by Team B. The purpose is to follow an end-to-end process to confirm that the functions are correct.

The problem also comes,

• The development plans of Team 1 and Team 2 are mostly developed independently, so it is difficult to develop the same function on both modules at the same time without any waiting between them. Fast development requires slow development. Although the story of one party has been developed, it cannot be tested and the delivery time is extended.

• When a bug is found during testing, it has been a day or two or longer, and other functions are being developed. Back to solve the problem, context switching is required, and time is wasted again.

• At the same time, it takes some time to locate the problem when joint debugging occurs.

In the previous project, we usedContract Test(Contract Testing) To solve this problem.

• First, the two teams determine the specific Interface format, which is equivalent to a set of contracts, and then the two teams develop their respective functions according to the contract.

• At the same time, Team 1 as the consumer adds a set of automated tests for this interface to ensure that Module B's functions comply with the contract. Each code change to Module B triggers this set of tests. If the test passes, the producer provides the correct function for the consumer. Otherwise, the producer cannot. In this way, Module B's changes will certainly not affect module A. Even if there is an impact, it can be reflected in the first time through testing.

This method saves developers' joint debugging time and QA can directly test the end-to-end functions. At the same time, it is easy to locate the root cause of the problem.

This test is different from the unit test of module A, and focuses on ensuring the correctness of the module's external dependencies. With this guarantee, the unit Test of module A can use Test Double (Fake, Mock, etc.) to construct A Test set that focuses more on its own logic, improve testing speed and stability.

There are two issues to consider when using this method,

1. Who will write the test?-This answer is relatively simple and must be written by the consumer to ensure that the test code and product code use the same calling method.

2. How to organize tests-There are two ways to choose from: Put on the consumer side, each consumer maintains its own set of tests; or put on the producer end, each module maintains a set of tests for this module. The first method is more likely to attract the attention of the relevant consumer teams, more targeted, but will introduce a certain amount of code repetition, the second is the opposite. In order to discover problems more quickly and more specifically, my team used the first method.

At the time of writing this, I searched by the way and found the article IntegrationContractTest by Ma. The basic idea is similar and the implementation is slightly different. In conclusion, manual joint debugging is a time-consuming and labor-consuming task, which can be less done, automation, and software life is too short to be wasted.

Link: http://www.ituring.com.cn/article/42460