Let's talk about tests, baby...

I just finished another TDD workshop, and I'm sitting in the airport waiting for my flight. As usual, I tried to emphasise that a single test should test one thing, and one thing only. As usual, people were having trouble doing that, which is perfectly understandable if you've only encountered the idea of TDD a few hours ago! To help people, I suggested that they articulate the objective of the test to their partner - "This test checks that ....." - and that if their description of the objective include "and" they should think about replacing that test with a number of more tightly focussed tests.

I also went a bit further and suggested that if the description could be expressed succinctly as "When X happens, we get Y value", then they were talking about a state test, and if the description could be expressed succinctly as "When we do A, B happens" then they were talking about an interaction test. I haven't tried to verify the approach yet, and I'm sure it won't be a blanket rule, but it seems like a reasonable heuristic. Since I don't get to program much these days, I'll look forward to feedback from people who do. :-)