James Carr has come up with a basic list of TDD anti-patterns and while I’ve seen many of them, one currently still plagues many of our tests:
A test that requires a lot of work setting up in order to even begin testing. Sometimes several hundred lines of code is used to setup the environment for one test, with several objects involved, which can make it difficult to really ascertain what is tested due to the “noise” of all of the setup going on.
The core issue comes down to having to use JSF for the GUI layer and dealing with its’ many mock objects using Shale’s mocking package for JSF. Thus many tests cannot simply test a single method without making sure FacesContext and many other stubs are setup. This tends to make the tests harder and more tedious to write especially for developers who haven’t quite caught the whole TDD bug anyway. The setup might not be hundreds of lines, but it is far more than you’d want for simple unit testing.
We’re still looking at ways to improve this from refactoring out even more code out of JSF backing beans to bringing in some TDD heavyweights to mentor the team through the best way to deal with it.