Read test-driven development and agile software development: Principles, models, and development

Although "test-driven development" is a thin book, it solves a lot of questions in my mind, but unfortunately it also brings a bunch of new question marks.

The process we develop at ordinary times is roughly divided into two steps: Determining requirements and coding implementation. Further details can be divided into n steps: Proposal of requirements, determination of requirements, compilation of requirements documents, database modeling and Object Modeling, coding, integration testing and acceptance testing. The coding process can be divided into n steps: Writing functional code and unit testing. Although such a process is not regarded as a RUP, I think it is moving towards the RUP.

However, from the book "test", I did not see the author's requirement to have a complete document in development. When I read it for the first time, I felt that the author had obtained the requirement from coding, but when I read it again, I denied my thoughts. Kent back, author of the test, took an example of Exchange Rate Calculation to show us how to use TDD. After the first unit test in the example failed, our lovely mr. kent has obtained all the requirements for exchange rate calculation. Now I am relieved. Should TDD be based on the actual situation? Is the demand actually driven by development? Impossible. What Should customers do in this case? This was my idea at the time.

If the problem is solved here, I don't have to write this article. Let's take a look at the steps in TDD to start the conversation.

TDD can be divided into three steps:

1. Write a test that cannot work. At first, the test program cannot be compiled.

2. Let the test program work as soon as possible, so some unreasonable methods can be used in the program.

3. Rebuild, eliminate repeated designs, and optimize the design structure.

Why do we have to write a test that cannot work first? Instead of writing a program that cannot work first? Why is development driven by testing instead of development first and then testing? Will the method of writing a program after writing test case cause lower development efficiency?

These questions have been around me for a long time. Although they won't make me feel difficult, it is a coder shame to let the problem last for such a long time. In light of the recent demands for transforming the members center in Jingdezhen and a few nights of thinking, some clouds have gradually been opened.

Why do we have to write a test that cannot work first? Instead of writing a program that cannot work first?

The test here is not a normal test. It is even different from the test we imagine. It is a requirement understanding. TDD requires us to write a test list before testing, which is more like sorting out requirements. However, TDD does not require us to make the test as detailed as the acceptance test. TDD requires us to clearly express the requirements.

Why is development driven by testing instead of development first and then testing?

TDD has a standard, that is, never write any program code without testing. TDD advocates small steps. Many things should be considered during the development process, including code correctness, scalability, and performance. Many problems are caused by the complexity, this leads to many times of "over-Design". Therefore, each step of TDD is only available. Today's things are solved today, and tomorrow's things will be discussed tomorrow.

Write firstTest CaseWill the method of writing a program after reduce the development efficiency?

This is my biggest question, but I have never practiced it, so I have no right to speak. Let's repeat the test-driven three steps:

1. Write a test that cannot work. At first, the test program cannot be compiled.

2. Let the test program work as soon as possible, so some unreasonable methods can be used in the program.

3. Rebuild, eliminate repeated designs, and optimize the design structure.

How can I use this test program to work as soon as possible? The following is an excerpt from test-driven development:

1. Pseudo-implementation. A constant can be directly returned.

2. explicit implementation: Enter the real code.

3. In the triangle method, a common thing can be abstracted from several aspects when there is uncertainty. Similar to a known triangle, a third edge can be obtained on any side of a triangle.

4. You can use copy and paste methods to make your program work as soon as possible.

5. Do not forget refactoring. This is an important step. Write the test you want before refactoring.

Maybe everyone shares the same feeling with me. The pseudo-implementation is too tough, and the pace is too small. But Kent back said, what kind of pace should I use to run, it depends on your feeling and experience. It's right to follow the feeling.

 

It seems that I can end it here, but after reviewing Agile Software Development: Principles, models, and practices these two nights, my mind is full of question marks.

XP is defined as follows:

1. Individuals and interactions> process (Here we advocate team communication and understanding)

2. software that can work> comprehensive documentation (this is the opposite of us and has doubts)

3. Customer cooperation> contract negotiation (requirements are constantly changing and understood)

4. Respond to changes> follow the plan (the development process cannot be static and understood)

5. The fewer functions contained in the initial delivery system, the higher the quality of the final delivery system. (Yes)

 

The following are more difficult to understand:

1. XP lacks a clear design stage (no wonder TDD is one of XP's most famous development methods, but what if the team members are not sure about it? What should I do if I leave the target ?).

2. In terms of teaching knowledge to new team members, the best two documents are code and Team (not everyone's code is clearly written, not everyone is good at communication. Will it be too idealistic here ).

3. Many teams fail because they pay too much attention to documents rather than software. (Will it exaggerate ?)

4. first describe your intention in the test (this is TDD ).

5. XP does not have a global view or the global view is unclear. There are the same questions as the first one.