I have visited the workshop of J.B.Rainsberger at our Finnish headquarters. It was very interesting for me and I have got a lot of very useful information about TDD. During whole workshop Joe made some online notes and because he told us that he would remove them after a month I have decided to save them below
- Put tests in a separate namespace, so that tests use the same interface that production clients use.
- Which test will force me to write the code that I think I need to write? This helps me avoid writing unnecessary code.
- Start each test with the thing you want to check. (Write the assertion first.)
- Run as many tests as possible as often as possible. Automate running tests to every time you press Save, if you can.
- Check one thing at a time. ((One assertion per test or one expectation per test) and one action per test.)
- Cutting code (or text) is dangerous. Instead: copy, paste, get the new copy working, then delete the old copy.
- Abstractions in code, details in data. Dependency Inversion Principle. Move duplicated data from the production into the tests. Move duplication from the supplier towards the client.
- Move code that validates input up the call stack towards the caller. Check data very thoroughly at the system boundary.
- Stub queries; but expect actions.
- Three Strikes and You Refactor; three copies is enough to remove duplication (two copies might not be)
- Make the weakest assumptions possible.
- When you mock an object, you are testing its clients.
- When you think you want to change something, but you're not sure how to change it, write more tests (add a new feature).
- If you can't invert a dependency, at least make it explicit (obvious).