Wednesday, October 28, 2009

5.4. Test First











 < Day Day Up > 







5.4. Test First



Having a good suite of tests is important�so important, that many developers advocate writing the tests for new code before a single line of the code itself! This is called test driven development, or TDD for short. Such tests represent the requirements that your code must satisfy in order to be considered correct.



To see how Eclipse makes TDD simple, keep the unit test you just created, but delete the Factorial.java file (select it in the Package Explorer and press Delete). The editor for the FactorialTest class will shown an error immediately because the Factorial class is not defined anymore. This simulates the state you would be in if you had written your test class first.



Put the text cursor on the first line that has an error and press Ctrl+1 (Edit Quick Fix). Select the "Create class 'Factorial'" option and press Enter. When the New Java Class dialog appears, press Enter to accept the defaults.



Now, go back to the FactorialTest editor and note that the compiler complains that there is no factorial(int) method. Press Ctrl+1 to create one.



Unfortunately, the current version of Eclipse is not always smart enough to figure out the right return type, so you may need to change the generated return type to be a double. Use a dummy return value (0.0) for now. At this point, Factorial.java should look something like this:





public static double factorial(int i) {

return 0.0;

}







Tip: Of course, this is not the right way to calculate a factorial, but all you want to do at this point is get the program to compile again.


Now you have a test case, a little bit of code, and no errors�so try running the tests. Unsurprisingly, they fail. At this point in actual TDD, you would go back to the code being tested and fix it so that it passes the tests, then add another test, make that work, and repeat the process until done.



Compare this technique with what most people typically do. They write a bunch of code first, then write a trivial little test program to exercise that code (maybe something with a main() method and a few println() statements). Once that test is working, they throw the test away and assume their class will never break again.



Don't ever throw tests away! Nurture them, slowly add to them, and run them often, preferably as part of an automated build and test system. Techniques even exist to create unit tests for user interfaces.




Tip: When you get a bug report from your users, your first impulse may be to fix the bug. Instead, stop and write a unit test that fails because of the bug. Then, change the code so the test works. This ensures your fix actually solves the problem and helps improve your tests over time.


The JUnit view is covered in more detail in Part VII. If you want to learn more about unit testing best practices, see:






http://www.junit.org





JUnit home page








http://www.testdriven.com





Resource for test driven development



















     < Day Day Up > 



    No comments: