Writing test should be part of the normal routine of every software developer. It is however not always the case. In his book ” Bad Tests, Good Tests”, Tomek Kaczanowski provides some interesting tips to improve your test writing activity.
* Doing things the right way takes more time than doing them any old way. But this extra effort usually pays off in the long term.
* Hard to write a test? Maybe the production code is of low quality? …or maybe you should consider writing tests before production code?
* Writing code is teamwork. Don’t forget to discuss these (new) ways of writing tests with your colleagues.
* It pays to (at least) scan the documentation of the tools you use. There’s a good chance you’ll find some hidden gems there.
* Be pragmatic, and let experience be your guide. It doesn’t matter if someone – even the author of a book – advises you to employ some technique or other. If it doesn’t work for you, simply don’t do it!
Reference: Bad Tests, Good Tests, Tomek Kaczanowski, http://practicalunittesting.com/btgt.php
These are simple rules that you can apply in all your programming and unit testing moments. Maybe the most important tips for me is the fact that if you have difficulties to write test it might be due to the structure of your code. Writing tests easily is a very good indicator of the quality of your code. It forces you to view you code and your software design with a different perspective.
Another good tip in this list is the one that discusses teamwork. Pair programming is a concept that can also be applied to software testing and having an external point of view on your test scripts and test techniques is a good way to improve them.