Thank you for giving me a lot of questions worth thinking. Here is an answer to these questions, I hope to help. The most critical, or try it again.
1. How do I guarantee the correctness of the test code?
This is a very practical, it is also a very common problem. I think this question doesn't have a very perfect answer. In fact, it is theoretically discussed more like "chicken eggs, egg growth chicken". The first thing to be sure is that we can't write a test code for the test code. Second, this problem can solve this problem by narrowing the particle size of TDD. In the Kent Beck's book, there is a special discussion of particle size, basically should write the simplest code to ensure the correctness of the test; and then the code is guaranteed by reconstructing and testing.
2, how much should the particle size of the test?
There is no fixed answer, if you are confident to yourself, granularity can be rough; if you encounter an error or problem, the particle size can be small.
3. Development of TDD is greater than the disadvantage to the development of the GUI layer?
As far as the workload of the current GUI layer test, if the GUI exceeds 10 (my personal experience and estimation), the TDD for the GUI is very valuable. Otherwise, it is not appropriate to consider from cost.
However, with the improvement of TDD tools, the cost of GUI TDD began to decline. I think so, I will not be too complicated to a small amount of GUI.
A tool worthy of interest is NUNITFORM, but also can drive the GUI test by writing code not only using the traditional way, but also automatically generates TDD code using the recording script.
4, how do you push TDD without TDD habits and ideas?
WITH MOST MEN, UNBELIEF INE Thing Springs from Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Blom Belief in Another.-Georg Christoph Lichtenberg
Therefore, under the auxiliary of one or two people with TDD experience, use TDD in the actual project, let everyone feel it. My personal feeling is that there is no basic, Team Lead must be based on the specific situation, according to the team's characteristics, the membership of the members, in the form of TDD form in the form of the project. Of course, the most critical is two points: everyone has an open mind; and the team is enough flexible and healthy discussion atmosphere.
5, how to ensure the full mapping and synchronization of the requirements (user view) and test code (TDD developer view)?
That is, the project success standards for synchronous users and TDD developers.
This issue is not only TDD problem, and various software development theories need to answer this question. So the answer to this question depends on the difference between the difference, the XP method is to drive multiple Test Case through a User Story.
I thought about it last night, I think about some of my thoughts, for reference: 1, I feel that this lecture is focusing, it should be an analysis (including using code) we often use "design, re-develop test mode" and The advantages and disadvantages of "testing the pattern after testing first, design and reconstruction", and the scope of them may apply, in which aspects have limitations, I think there is a universal pattern to solve all the problems, whether it is the first A model is still a second mode. A pattern is completely replaced with another mode.
2, as far as my level and my eyes, or for my habits and thinking, I like "the mode of design, re-develop test", until I want to clear the code again. For me this kind, if you ask for the use of "Test ahead, design and reconfiguration", at least you should convince me, this new mode is better than what I use now, and it is more advantages. Otherwise I won't change my habits, or there is no motivation to change the status quo. In particular, when the demo code, constantly refactoring, pushing, pulling down, I can recall when I go back, it is a "chaos" word, then I will instinct this new mode. 3, NUnit test is very important, this is estimated that no one will oppose (Gary, Shut Up! :-)). But in the end, it is a means, or the status of the entire project drive should be considered.
4. You can talk about the shortcomings of NUNIT.
5. Yesterday, I said some of the questions in the lecture. I didn't talk about politeness. At least, at least the lecture didn't persuade our people who were still using the first model; or the lecture is not very compact, did not catch the audience Attracting the audience, causing the audience. Of course, it is difficult to think, especially my listeners who never think. Running again.
I thought a little this weekend, I feel that it may be possible to combine the "institutionality and deterministic" of Design-first, "security" in TDD, I want to test this Idea this Tuesday, I hope I can hear it. Your feedback. In addition, I also rereaded the PPT and added more thinking and feedback, but time I didn't know if it was enough. This is why there is a reasons for a preview every time.
In the range of use, I have a relatively extreme point of view that more than 1 person 2 month project, should use TDD. Of course, as mentioned when I started, TDD should be a way of thinking, not just a skill.
I think Test Driving is a good design and development method, which is very suitable for use in some occasions. Great software is not designed, but a little bit of done, once an instead of once, a repetition of an ideal and realistic conflict and compromise, this is the reality of software development. Test Driving is designed and developed with such a realistic attitude. It is realism; and after a strict design, the way I think it is ideal, but the ideal is in front of the reality. I have to smash, I think everyone has the same feelings. Realism and idealism have their respective martial arts, but realism is suitable for more occasions. I think Test Driving Applicable Places: 1 Abstract underlying code, basic demand is stable, can repeated Refactor; 2 business logic layer code, can be changed after change, know that all business features can not work, on the one hand, can refactor, On the other hand, it is possible to resist demand in a certain degree of resistance; Test Driving is not applicable: 1 is very familiar with the field, first design and re-development is a good method, directly doing 2 needs unstable business logic The layer of code, written, will become useless due to the needs of change, become wasteful. 3 interface programs, but this is because now NUNIT is not strong enough
I think that the discussion of the dead is basically consent, but maybe it is a demo, my overall feel is that everyone feels very confusing. In fact, I was very clear about my idea. For unabled 2, I first agreed that there were some test code because of the demand variation, but from another angle, if the demand change is frequent, the demand, structural changes are also very frequent, this The situation is that the TDD can really display the role. I personally think that the TDD should pay close attention to the correctness and neat problem of test code itself. It is very important to do Clean and Work. When the TDD is in a bad way, the test code is very brittle. The result is a change, and many test code will change, and the maintenance test code itself has brought a small workload; this requires test code to constantly refactoring. To ensure the uniqueness and effectiveness of the test. So, what mechanism is guaranteed to test the refactoring of the test code? There are already some functional code protection, first determine that the test code is correct, then reconstructing, if the test is not passed, the test code has a problem, and there is a fundamental principle to absolutely modify the functional line at the same time. Code and test code, otherwise a correct reference will be lost. http://dongxun.mblogger.cn/posts/4848.aspx
