Unit testing
This is taken from my reply to an artcile on theserverside.com regarding unit testing
One of the things that Mike Spille states in his article was that anyone can write a better test framework in a day. It may be true, but when you are concentrating on developing your application, you shouldn't be wasting your time building another framework and use most of your time developing your own application.
Its basically the same concept as using the jakarta commons libraries, most of the things in there we can do ourselves, but the question would be why bother re-writing the piece of code over and over again. And if you try to justify saying that you'd want your own private library with little dependencies, you have to ensure that you maintain those small pieces of code over and over again rather than taking advantage of what is already out there.
Using JUnit is quite simplistic I have to agree. But would you rather test your small routine with the entire application all at once or just write a simple test case. Sure you can just create a main() method or separate class to test it out, but writing a JUnit test is similiar to writing the main() method anyway only there is some IDE and tool support for the tool so you can take advantage of the reports it would generate.
Assertions in JUnit actually prevent you from having to look at your test run once you decide what the correct output is supposed to be. I cheat and sometimes use printlns to display the result and copy and paste it into the assertions, because the result is sometimes too tedious to type.
JUnit being lightweight is not a hinderance, its a bonus for it. Being lightweight allows it to be easily embedded into other tools such as JPerf, Eclipse, Ant and Maven. Its also easy to prove that it just works because it does so little.
Of course I wouldn't use JUnit alone when I do integration level testing (that's just nuts at times since its going to make my test case longer than it has to be). I'd use extensions to JUnit such as HttpUnit, StrutsTestCase, JFCUnit and Cactus. Tools like HttpUnit (and a bit of refactored code to reduce the code base I maintain) allow me to translate Use Cases to test code to verify that things flow as expected (of course that would take a bit more experience to do since it is more complicated). And integration level tools allow me to regression test cheaply.
I am not as ridiculous and run all unit tests all the time on my development PC, that's just nuts. I wait till the nightly builds execute and run the test cases for me and let the build manager assign blame appropriately.
As another person said on the thread, unit tests also aid in refactoring. I usually some deadlines are hard and I just write whatever to get the thing working. The code I write may not be good and/or it might just be a 1000 line class, but it works. I don't write my JUnit test cases then just make sure that the demo works. Once I do get that working, I just add the unit test case afterwards, something minimal where I just prove that a boundary value works properly. Then I go on to another component. Usually, I will come back to that piece of code later, the most common reason being, I have to cut and paste come code from it, at which point I do a bit of refactoring to reduce the code base (I want to reduce the active code base as much as possible, because its harder for new people to pick up if the code base is too big).
And to rebut the other thread where someone said that unit tests take 2/3s the time to make. I've been on application maintenence group, most developers who haven't gone through that probably just write code to get the customer happy and pay, application maintenance teams have to make sure the bloody thing runs everytime and figure out why something goes wrong. Working on application maintenance does build up sufficient skills, wisdom and maturity to find ways of avoiding code problems before it gets to them.
Automated unit tests are a useful tool when you have teams who have to make sure that the code works because it reduces the costs for them to fix any bugs that the development teams make, by reducing regression costs. Of course like any part in application development, they have to be done properly.
To finish this reply, here are some rules which I personally have trouble myself from doing when I write test cases. (in order of difficulty)
- make your tests throw exceptions (don't bother catching them unless you need to)
- write at least one sentence on what you are testing
- refactor your tests, a lot of tests can get common setup and teardown routines
- put unit tests reports as part of your nightly build cycle.
- turn use cases into test scripts
- build data that you are testing on, don't rely on data to be there.
- remove data that you are finished testing with if possible.
- make things testable without the container
x-posted in
trajano 