I do TDD, and I’ve been fairly loose in organizing my unit tests. I tend to start with a file representing the next story or chunk of functionality and write all the unit-tests to make that work.
Of course, if I’m introducing a new class, I usually make a separate unit-test module or file for that class, but I don’t organize the tests themselves into any higher level structure. The result is I write code fast and I believe my actual program is reasonably well structured, but the unit tests themselves are ‘messy’. Especially, their structure tends to recapitulate the phylogeny of the development process. Sometimes I see myself as trading laziness in the code for laziness in the tests.
How big a problem is this? Who here continually refactors and reorganizes their unit tests to try to improve their overall structure? Any tips for this? What should the overall structure of tests look like.
(Note, that I’m not so much asking the ‘how many assertions per function’ question asked here : How many unit tests should I write per function/method? I’m talking about the bigger picture.)
Divide your tests in 2 sets:
Functional tests are per-user story. Unit tests are per-class. The former check that you actually support the story, the latter exercise and document your functionality.
There is one directory (package) for functional tests. Unit tests should be closely bound with functionality they exercise (so they’re scattered). You move them around and refactor them as you move & refactor your code around.