Bad Tests Good Tests
I'm happy to announce the arrival of my new book! :) It is called "Bad Tests, Good Tests" and is all about writing high-quality tests.
I can't remember when it started but since some time I was collecting "interesting" pieces of test code. By "interesting" I mean the ones that could be well improved. After some time I noticed there are some (anti)patterns, some typical bugs, or rather imperfections which I observe frequently when reviewing test code.
I try to write my tests so they fulfil some basic requirements. They should verify some important part of the system. They should survive refactorings. They should be readable, clear and concise, so you can read them like documentation. They should be fast.
When discussing unit tests it often happen that I hear that "unit testing is about testing methods". I do not agree, and because this is something which surfaces here and there so I think the idea deserves a comment.
My blog was quiet recently and for a good reason. The thing is that am working on a new book. Well, on two books, or maybe rather one and a half book. ;) Ok, here is the story.
I've promised to publish the slides from my JDays 2012 presentation "Bad Tests, Good Tests", so here they are.
There are some things which are not worth unit-testing. Really, there are. Getters/setters and delegators are the best examples.
If we expect our tests to act as a documentation then we need to put some effort into their readability.
For unit tests a rule of thumb is to keep them independent from each other. It is not so bad if we introduce a dependency on purpose (and explicitly declare it e.g. using TestNG
dependsOnMethod feature). A worse scenario is when we are not aware of the dependency ourselves. This can bring serious problems on our heads.
I'm looking for bad test code, so if you have some, please send me!