A method in the preparation prior to the preparation of its unit tests, or finish this method, even after the entire class to write unit tests do? John Ferguson Smart [1] in his blog raised this issue again, and according tohis experience gives some suggestions.(2008.06.10 Last Updated)
Are not pedantic.In a way you write unit tests before or after the write - in my experience, if you write the code in almost the same time to consider and write unit test program, then this is irrelevant.Again after the return to (or simply do not go back) to write the test program will cause problems.For me personally, I like to write a small amount of code before or after followed by the preparation of unit test - it will not break the workflow, because it is part of the process.
This requires a bit of practical experience - the lack of experienced developers often write what kind of test procedures and trouble.But this may also reflect the fact that: they do not know what to write the same kind of code.TDD can encourage some people comment on the micro design - a very low-level design, it does not take into account the larger scene.This will happen in the absence of experienced developers who; If you dogma camel Using this approach, the same will be met.Such as behavior-driven development approach here would be cool.When you write getter method before, you will write a getter method for this unit test? If so, then your unit tests focus on the higher level, and also closer to the user (or system) requirements.
Back to the nature of the problem, why do I like to unit test on the starting position? Very simple! My experience tells me that can help improve the quality of code and saves debugging time.Ten small writing at the beginning of the unit test time spent Bug fix in the future than it takes less time, if the code unit testing through the correct, then there will not be a Bug.
In fact, I often see, if some code after the appropriate unit tests, then there will not be coding problems.There is a recent example: It took an hour to search a problem in Web applications, the problem appears in a Spring-MVC to write correct programs.The result is a test class as an exception ignored.It is easy to find the problem, in fact, after reading the code (code inspection (Code Review) is also very effective) immediately after the discovery.But the key is, we spent an hour or more time to find the class that needs to be checked.If the code after the appropriate tests, then you can quickly find and solve the problem.
In my experience, when people in the preparation of your program before starting to write unit tests, just as the idea only after difficult for them to write the test ("I have completed all of the code, this time I alsohave to write unit tests ").Or do not do it.In this case, the code is completed? If code is run to very good, it would be done.In this case, write unit tests to significantly lost its value.Also Not only that, after writing the unit tests will be shallow, not well tested code.Alternatively, the developers have consumed over time, they do not want a lot of trouble for the unit tests.
TDD and, like any other coding practices.When you are learning a new technology, you will tend to guide every step of learning.Similarly, when you learn a martial art, you will try to imitate the master step by step movement, without having to understand the logic.Once you become familiar with a technology that can skillfully use it, and a deeper understanding of it, and then, you can improve it, and before you master the fusion of other technologies.
Annotation
[1] John is the Java Power Tools book's main author, also in an active java.net Bloger.
After translation
This week saw the java.net Blog, and then think their work in the usual practice of unit testing, some mixed feelings, it will be translated out and share.
Write unit tests in advance, or afterwards to write unit tests? This is an old problem.TDD in accordance with the idea of nature is to write unit tests first, then write to the adoption of the unit test method.
However, unit testing, TDD is not the exclusive territory, many of the projects are not practical application of the TDD unit testing.
I think that practice TDD without the project (my own surroundings is the case), there is still a writing unit tests after reasonable to:
1. To a negative point of view, since the project itself does not strictly require prior written unit tests, it can be done after the fact was.This at least is better than not to do, better than nothing Well.(Hey, is negative enough, but you can not get)
2. After writing a unit test is a test at least means, of course, certainly not as pre-writing unit tests.Because, after writing the unit tests are likely to "will" has been written application, as John said, "after writing the unit tests will be shallow, not well-tested code."But ... is still better than nothing Well:-D (Haha, is there for poured a)
3. Can unit test, which will contain after the unit testing, as "latecomers" to understand and learn the means of the application.Because unit testing program is the application of the "customer", so whether it is written in advance, or afterwards to write, are able to demonstrate the behavior of the application.
4. After the unit tests may also be converted into pre-unit test.The entire application life cycle, maintenance stage is the longest.In the "long" in the maintenance process, "before" written "after" unit test will be the "latecomers" (including the original author) of the "prior" unit testing.In the process of improving procedures, these unit tests can still play a supervisory role.(Orz, a little sophistry)
Although obviously not as good as the prior unit test after unit test, but its role is still not be underestimated.As long as the unit prepared an excellent testing program, no matter at what stage, it will improve the application of great help.(This is not "better than nothing," can express)