When starting a new piece of work using CodeUnitTestFirst, it seems to me that often the hardest part is getting started. ChoosingTheFirstTest would seem to be an important part of this. But what kind of test makes the best first test?
Imagine the first test you might write for each of the following situations:
A PDF generator.
A natural language parser.
A relational database.
An autopilot.
A reporting tool.
A CRM system.
Anybody care to take a stab at some of these?
Aren't these projects a bit too big (as in undivided, poorly specified) for you to start writing tests? See ChoosingTheFirstChoice for a "work-sheet".
You're probably correct. Okay then, let's suggest some smaller tasks and the corresponding first test.
I do not think the topic is too broad. But I do not think there is a guideline which will pop up the correct first test.
I once wrote a ConfigurationManagement system for a large hardware/software design project. If the first test had not been successful, I would not have had the opportunity to complete it. The first test's purpose was to show the customer that my concept was feasible. The test showed the customer that the required relationships between documents could be maintained, and showed how it could be expanded to include additional relationships - like design requirements, standards etc.
So my first test was seen by the customer as working software, which is the beauty of XP.
-- PeterLynch
Parsers are probably among the easiest things to write tests for. It's a predictable unambiguous input->output function, and it has no side-effects. -- WouterLievens?