Teaching testing habits to other developers?

Question

Developers have many different options out there to create fast and relatively maintainable unit test suites. But this takes a great deal of knowledge involved in decoupling modules of code, isolating the code under test within its test context, and using test doubles (stubs, fakes, mocks). What's more confusing is that within the concept of doubling itself, there are many different approaches that are vastly different from one another:

• Using dynamic languages/metaprogramming or instrumentation approaches to override implementations of methods (even static methods or initializers) for the duration of a test run.
• Interaction based approaches based on defining expectations and recording expected calls on doubles.
• Using "fake" double implementations provided for testing with a third-party framework you're using.
• Creating your own stubs.

This means while someone may be familiar with the "mock" objects (I prefer to call these fakes) provided by SpringMVC, for instance, some interaction-based mocking code can leave the same person scratching their head. (Is this what happened to Hitler's developers?)

My experience has been (and I suspect others have seen this, too) that very few developers are familiar with this requisite knowledge, and even fewer have enough expertise to develop suites that are somewhat maintainable. (Let's face it, maintainability is a very relative term when we're talking about tests!) Furthermore, often I'll see developers break a test they aren't familiar with and their first instinct is to comment it out rather than fix the test or the code that is broken. Time is often lost in the long-run, but it seems less painful initially.

On your team, how have you dealt with educating and addressing maintenance problems that come about when we don't understand each others' test code?

Answer 1

I have found the following have helped:

• Create and enforce naming conventions for tests.
• Follow the Arrange, Act, Assert pattern, no matter what.
• Consider setup methods a very strong code-smell in tests.
• Create good examples and exercises for each doubling technique.
• Post visual feedback of test metrics where other team members can see.

Answer 2

I work in a 15 member team in a company that's anal about Test Driven Development, so we come across this problem fairly often. The reason I say fairly often rather than 'every five minutes' is because we try to follow these practices:

1. Pair programming and pair rotation: although only a few members at the beginning have the know how and experience for TDD, pairing very quickly spreads the knowledge around. We have freshers who come in, work with the people for one week, and start lecturing on testing strategies. This also involves rotating the pairs, so everyone works with everyone else regularly.

2. Keep great test naming conventions: We try to name our tests very expressively. Examples include public void testThatSavingTheOrderDispatchesItBeforeWritingToTheDB(). While it may seem funny, this makes for very productive testing, especially when coupled with sensible and readable method and variable names.

3. We also read up on the latest mock and testing frameworks available. Tools like Mocha / RSpec (Ruby) and JUnit / Mockito (Java) are very powerful and can be learned in a short while. There is a learning curve, but its well worth the effort.

4. Once you choose a testing and mocking framework, keep only that framework. The top few frameworks in any language are usually only different in terms of syntax, not power. So there isn't any reason to pollute the code with more than one way to do the same thing.

5. Nothing beats training, self motivation, and working closely with those who already know. I've learnt the most testing in one hour working with a fellow programmer who worked with a senior programmer for two weeks :D