Looking at TDD from newbie’s point of view

Looking at TDD from newbie’s point of view<o:p></o:p>

<o:p> </o:p>

 

<o:p></o:p>

[e-mail]<o:p></o:p>

 

<o:p> </o:p>

Preface<o:p></o:p>

Many times heard people says that test is vitally important for software developing and kinds of test methodology, after have been developing Java web application for over a year, I deeply realized that test is the combination of experience and technology. Last Friday I accepted JUnit training, the training showed us TDD and the teacher shared his experience of test, it is excellent. Now I will share what I learnt recently.<o:p></o:p>

What is TDD?<o:p></o:p>

TDD is abbreviation of Test-Driven Development, is a core technology of XP (eXtremely Programming), but this methodology can do many help for testing our software even though it not being developed in XP process. Here you may doubt what XP is, I would tell you just Google it.<o:p></o:p>

XP philosophy<o:p></o:p>

Any methodology has its own philosophy, so XP too. Communication, Simplicity, Feedback and Courage are the four values sought out by XP programming. We can see the human character of XP, cannot you?<o:p></o:p>

TDD steps<o:p></o:p>

We can do our TDD by doing the following steps:<o:p></o:p>

First, understand and simplify the requirements<o:p></o:p>

Second, think over you test-driven and complete it<o:p></o:p>

Third, complete your business classes or methods which are being tested by your test-driven<o:p></o:p>

Finally, run you test-driven and make the test pass<o:p></o:p>

If the requirements were changed, just do the same steps mentioned above<o:p></o:p>

If the code smells bad, refactoring your code.<o:p></o:p>

<o:p> </o:p>

Actually, here refactoring is the most important step, and it need developers experienced. We may ask what is refactoring, there is a book--- Refactoring by Martin Flow showed us what it really is.<o:p></o:p>

Why it is better?<o:p></o:p>

Now we might have seen that TDD is not only for test, but also for design. It is better for the following reasons:<o:p></o:p>

First, most programmer would prefer code to documents, and the test-driven is a good idea to solve the problem.<o:p></o:p>

Second, test-driven make programmer do their work confidently. They can test they code any time and have the reason believe that the code is right.<o:p></o:p>

Yes, they must be more, but the first statement in this section is enough. TDD is not only for test, but also for design. <o:p></o:p>

Some rules<o:p></o:p>

First, developers must write test-driven for his(or her) class or methods.<o:p></o:p>

Second, write test-driven for classes or methods you believe must be tested not all methods or classes.<o:p></o:p>

Third, run you test-driven any time and make your code clean.<o:p></o:p>

Forth, refactoring your code if it looked ugly anytime.<o:p></o:p>

Mr. Robert C. Martin showed us his rules:<o:p></o:p>

You are not allowed to write any production code unless it is to make a failing unit test pass. <o:p></o:p>

You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. <o:p></o:p>

You are not allowed to write any more production code than is sufficient to pass the one failing unit test.<o:p></o:p>

See more and detail on his site, there is a link in the bibliography of this article.<o:p></o:p>

Using JUnit in TDD<o:p></o:p>

Keep the bar green to keep your code clean, it is JUnit. It is a tool gives us the ability to write our test-driven conveniently. Reduce percent of mistakes in our test-driven. It is easy to use and make our test-driven develop more efficiently. Of course, JUnit is not enough, there are kinds of auto-tools can work with JUnit. Just find out our Mr. right.<o:p></o:p>

Using JUnit in out-sourcing<o:p></o:p>

Condition is special in out-sourcing development, especially in out-souring for Japanese, here developers have been deprived their last freedom. When we make our decision use JUnit to test our program, the following questions should have been thought over carefully.<o:p></o:p>

First, get agreement of JUnit from our customer.<o:p></o:p>

Second, customer would like to pay for test-driven<o:p></o:p>

Third, customer wouldn’t mind there are no test documents<o:p></o:p>

Forth, make sure our team has the energy and experience<o:p></o:p>

Fifth, test is for experienced member, not newbie<o:p></o:p>

Six, for GUI test, auto-test won’t work any longer<o:p></o:p>

Experiences<o:p></o:p>

Auto test is a lie for lazy developers, anytime and anywhere, men will be ever the core. Think everything over carefully.<o:p></o:p>

Summary<o:p></o:p>

I am afraid the article a bit off topic, but I don’t think it won’t do any harm to the goal of showing experience on testing. There is nothing can be absolutely depended on except our self, our knowledge, our experience and our intelligent mind.<o:p></o:p>

Bibliography<o:p></o:p>

http://www.butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd<o:p></o:p>

http://blog.csdn.net/rmartin/archive/2006/08/17/1089322.aspx <o:p></o:p>

http://www-128.ibm.com/developerworks/cn/linux/l-tdd/<o:p></o:p>

http://pag.csail.mit.edu/continuoustesting/<o:p></o:p>

http://caterpillar.onlyfun.net/Gossip/JUnit/JUnitGossip.htm<o:p></o:p>

<o:p> </o:p>