FAQs during TDD implementation

In a recent infoq article titled frequently asked questions during TDD implementation,
Chad Meyers raised the following questions about TDD implementation:

1. How much pre-design can I tolerate? How do you know when to stop (that is, "When people start to discuss algorithms, this is the time to test ")?
2. For something like "I know in my mind that we need this"-how do we handle it (for example, add a try/catch {console in the main () method of the console. writeline (Ex );}?)
3. During testing, you have to write one or two interfaces, one entity class, and some notimplementedexceptions in the class to make the code pass. How far should this step be taken?
4. If you find that there is a problem with the previous pre-design during the test of a user story, you will immediately stop to discuss it with your partner, do what you should do, and then continue; or roll back, what is the complete test priority model used in the current story?
5. When dealing with a new user story, you find that the tests written for the previous story no longer reflect the requirements. Will you refactor the test immediately, or mark it as "Ignore", and wait until you finish the current story and go back and process the ignored test? Is there any other way?
6. If a new user story requires a slight adjustment to an existing test, will you adjust it, or write a new test and discard the old one (that is, "Do not change the existing test code! ", Or "it can only be triggered when a small compilation problem occurs. Otherwise, don't touch it !")?
7. If you build a model and pass the test, but you find that this design is naive, and the upcoming user stories will certainly make significant changes to it, and generate a new completely different model. You should leave
   Step 1: Do you want to perform large-scale reconstruction? Should we continue to repair and supplement the existing model, even though this model will eventually be improved by the work that seems to be beyond the scope of the user's story?

Derick Bailey shared his views on Chad issues. The following is an excerpt from his answer:

1. Just Know what you should build.
   This question should be answered based on your actual project. I recently developed an enterprise integration project that uses our core maintenance system and adds some offline operation functions. In this project, I
   There is not much pre-design. I know that the system needs to be able to operate in offline mode. I also know that it needs to be able to perform some operations even if no one is logged on to the computer or running the software.
   Performs two-way communication with the primary Maintenance System to execute a certain number of maintenance-related tasks. I started from some ideas/pre-designs-built a Windows
   Service to run core processes, build a client-server architecture to host the UI, and provide communication support in a messaging system. Besides being pre-designed
   Are the functional requirements of other tasks to drive the progress of project design.
   Recently, when I worked with a team that developed a system for a lab, I had a very opposite experience. We focus on the customer's needs, the customer's required processes, and the customer's data conversion needs;
   We need a large-scale pre-design to determine that our solutions can meet data conversion and functional requirements. The core design of the system is completed in advance, but the specific implementation is slowly developed
   Type.
2. This is a question that allows me to fight in my heart. To answer it, it depends on the time when this problem occurs. I don't want to add features and features unless I know they are needed now-when this issue involves the application's domain model and core infrastructure. However, for issues like console. writeline (Ex), I don't think there is much debate to add these features to the main method of the application. After all -- you will not perform unit tests on the main method of the application ...... You will test the integration.
3. For the implementation interface, I do not want to write the pile object manually. Instead, I will try to use rhinomocks as much as possible to avoid this problem. I used to write a pile of code at any time, including a dozen unimplemented methods-the results make it difficult to maintain my unit test, at the same time, a large number of repeated pile objects are provided for the methods identified in the unit test.

   You should add only the methods you need. If you have a real object that contains the unimplemented exceptions to be thrown, you may need to check this method to see if it can be deleted from the code base.

4. This issue still depends on the specific issue.

   I spent a lot of time developing Pair Programming with my partners. We are constantly encountering a scenario where the next functional requirement will lead to changes in the existing design. If something like this happens, we will only modify what we need. We will write new unit tests for some new features. If the previous design makes our unit tests fail, we will return the design before the modification -- modify and update the unit test within the scope of the modification. In this case, unit testing is considered as a mandatory list. When we modify a completed design, we usually forget the modified scope or the new functional requirements we are trying to meet. Fortunately, through the complete operation of the entire unit test suite, We can display the damaged test and remind us to modify it.

   During the end-to-end programming, we have many opportunities to get new requirements, review our design and implementation, and identify that the entire model is wrong through understanding this specific requirement, we need to write it from scratch. At this point, we did something that many people did not think about-we deleted all classes and unit tests in the system, and then started from scratch. The lessons learned through this method and the understanding of other needs can lead us to start a new design that can consider the features we need -- however, we can still write existing functions based on what we need. Although we have not created "future code", it provides scalability through additional interfaces and abstractions ......

   I have repeatedly stressed a cycle like "design, modification, redesign, modification, re-build, and modification ". Based on my experience, the final result is worth doing this-less bugs in the system, more accurate representation of the business needs model, better scalability and flexibility, this allows future modifications.

5. Fix it as soon as possible. If you do not fix it now, you may do more work in the future, because some new content will interact with the wrong content, in this way, you must modify the error content and new content at the same time. If you modify the wrong content now, you do not have to rewrite the new content later.
6. If you are modifying the meaning of a test (for example, renaming a test to accurately express the content and cause of the test), you can automatically delete an old test, create a new one-even if you only delete it from the semantics, you only need to rename it and modify little details. If the meaning of the test representative is still the same, you can modify only some implementation details (because according to question 4, you modified the design) and then keep the test, instead, we only need to modify the implementation to meet the new implementation needs.
7. See the answer to question 4.

In addition, Derick Bailey also talked about other TDD problems, such as comparison of assertions, analysis of setup methods, and understanding of refactoring tools.

My answers to these seven questions are as follows:
1. The pre-designed degree does not have an accurate value. First, for a system, it is necessary to analyze the technical key points from the perspective of the field and architecture and pre-design these key points. In addition, we also need to pre-design the system's infrastructure content, unless the content already exists. In fact, if the domain-driven design is used to analyze the domain logic, there should be no ambiguity when to start testing. It has its own set of rules that need to be followed. TDD does not completely eliminate the role of design. It uses testing to drive development. In fact, it also means that we can use testing to drive design. Therefore, my opinion is that if we regard each component of the system as a package or component, the ideal starting point of TDD should be after the package or component is divided, we can use unit tests to drive our thinking and coding on the domain model.
2. There is nothing to say about this problem. If it is an example of the problem, I think there is no argument. As Derick Bailey said, we do not actually perform unit tests on the main method. I agree with Derick.
3. Obviously, if tools can be used to simulate pile objects, why not? If the interfaces and entity classes that the test code depends on are what we need to implement the system, it is useless to implement them. At this time, I agree to define or implement them first. However, while defining and implementing them, we need to consider that these definitions are not necessarily complete and accurate. We also need to consider modifying them at any time. After modification, we must also check your test code.
4. Why do we need to let it go for the time being when a problem is found? My thinking has always been to put errors in the cradle. Otherwise, we will always be troubled by this problem. If you cannot confirm these errors, it is better to discuss them out.
5. Similar to Issue 4.
6. For details, see the scope of the modification. If the test case that needs to be modified does not affect the dependent test case, that is, it does not modify its external interface, you only need to modify part of the implementation code. There is no need to write a new test case. If you need external interfaces, you can consider refactoring. For example, the rename problem mentioned by Derick. If refactoring cannot be solved, you can write a new test.
7. Obviously, it is the same as Issue 4.