Selecting a First TDD Exercise

Kata “Kata,” courtesy Peter Gordon. License.

Introducing developers to TDD? You want to carefully choose a first exercise. Too short, too long, too simple, too complex, too toy-like, too close to their problems, too whatever, and you might have chosen a turn-off. First impressions matter!

Of course, you can’t please everybody, but you can usually find a good middle ground. Here are some criteria for selecting an appropriate first TDD exercise.

Not frivolous. While very many of us love games and trivialities, there are enough developers that don’t. Their takeaway: “TDD is just for toys, not the ‘professional’ development that I do.” The Bowling Game? Save it and other games for a second or later exercise.
“Real” enough. A dozen years ago, I used to demonstrate a stack example in Java. Its implementation was a trivial four methods that simply delegated to an underlying list. Same takeaway: “Why would I bother building such a thing? TDD is just for toy examples.”
Time frame: Not too short, not too long. For a very first exercise, something that takes learners about 25-40 minutes to implement as a pair is ideal. (For experienced test-drivers like you or me, this translates to about 10-15 minutes as an individual and 20 minutes in a pair.) Any longer and they’ll get frustrated; much shorter and they won’t have had a chance to get into the rhythm.
Promotes incrementalism. Part of TDD’s power is in its ability to help you incrementally grow an implementation in a series of small steps. A ~45 minute example as suggested might involve 5-7 individual tests. As a counter-example: Looking for a Benefactor, a challenge at the kata site CodeWars.com, provides a decent challenge. However, the end-implementation is fully codeable with a second test, and there’s perhaps only one additional (denegerate) test to try.
Allows alternate solutions. Just about everything does, but if there’s one and only one decent way to code it, find something that allows for more interesting choices.
Mild problem solving required. You don’t want learners to bog down on thinking terribly hard about the problem itself. Yes, they need to think, but not so much that they’re distracted away from the core concepts and technique of TDD. For this reason, problems requiring “interesting” math are probably not a great idea for the average IT developer. Think simple.
Promotes refactoring. The ability to refactor with confidence is perhaps the primary reason to do TDD, so this criterion is quite important. You want strong reminders at refactoring steps that the code will get out of hand without incremental cleanup. It’s likely that problems promoting incrementalism and requiring “mild problem solving” will provide enough refactoring opportunities.
Allows mistakes. Mistakes are great learning opportunities! You want the possibility for an average learner to make up to a few stupid (or not so stupid) mistakes when implementing a solution. It’s even better if they are also likely to make mistakes when refactoring.
Minimizes esoteric language knowledge. A good developer shouldn’t have to Google something to figure out how to implement a solution.
Potentially expandable. While there’s something to be said for “done,” having an example you can build on later, or add to for fast learners who are ahead of others, can be worthwhile.
Fun enough. Not a toy example, but something that programmers might enjoy enough to quickly relate to and dig into.

Knowing your audience can help you refine the above to chose an example even better suited to their interests!

One example of an exercise that I’ve found to work well: acronym generator, also at CodeWars. It can be done with or without regex string splitting, and the regex is simple if that’s the route the developer chooses. There are ample additional requirements you could introduce (salutations, suffixes, resolve clashes, etc.).

Mind you, this is all for a first example. Subsequent exercises can be as meaty, long, goofy, or tricky as needed!

The Compulsive Coder, Episode 7: Please AAA

Q. What behavior does the following JUnit test describe? (In other words, what’s an appropriate name for the test?)

        MockInitialContext mic = MockInitialContextFactory.getContext();
        mic.map.put(ClassicConstants.JNDI_CONTEXT_NAME, "tata");

        LoggerFactory.getLogger(ContextDetachingSCLTest.class);

        ContextJNDISelector selector = (ContextJNDISelector) ContextSelectorStaticBinder.getSingleton().getContextSelector();
        Context context = selector.getLoggerContext();
        assertEquals("tata", context.getName());
        System.out.println(selector.getContextNames());
        assertEquals(2, selector.getCount());

Maybe it helps, just a bit, if I tell you that the test name is testCreateContext.

Why must I spend time reading through each line of a test like this to understand what it’s really trying to prove?

The test designer might have made the central point of the test obvious, by visually chunking the test into its Arrange-Act-Assert (AAA) parts:

        MockInitialContext mic = MockInitialContextFactory.getContext();
        mic.map.put(ClassicConstants.JNDI_CONTEXT_NAME, "tata");
        LoggerFactory.getLogger(ContextDetachingSCLTest.class);
        ContextJNDISelector selector = (ContextJNDISelector) ContextSelectorStaticBinder.getSingleton().getContextSelector();

        Context context = selector.getLoggerContext();

        assertEquals("tata", context.getName());
        System.out.println(selector.getContextNames());
        assertEquals(2, selector.getCount());

Well, I think that’s right at least, given what we know.

(Yes, the word “test” in the name duplicates the requisite @Test annotation. And yes, there are other problems with the test, e.g. printing anything to the console. But it’s excruciatingly simple to first ensure the structure of a test is clear.)

Standards are only that if they are constantly adhered to.


Previous Compulsive Coder blog entry: this Duplication Is Killing Me
Next Compulsive Coder blog entry:

Atom