- Everyone knows the basic cycle of TDD.
- You should also know the improved Industrial Logic version of the TDD cycle.
- You have heard Uncle Bob's three rules.
But there is so much more to know.
I have been gathering little sound bites for you which may help you build your skills and knowledge.
Please feel free to drop additional factoids or questions. I'm happy to explain any of these at length if you like.
Here is my list:
- Your code has two parts: the part you have covered with TDD, and the part that requires you to use a debugger.
- Microtests are F.I.R.S.T. (you cannot TDD after writing the code)
- Only microtests are appropriate for TDD; other tests are useful, but not for TDD.
- Microtests are not all your tests - you need other levels of test still.
- TDD does not validate your system; it only speeds development and improves quality.
- TDD without a pair programming partner is like programming while wearing only one shoe.
- TDD's power is in the shortness of the cycle and the constant invitation to evaluate and refactor; this is why test-after doesn't yield the same results.
- We absolutely will unabashedly change production code in order to make tests pass (e.g. to make it testable)
- If you don't do the 'refactor' and 'integrate' steps of the cycle, it can only end in tears.
- Depending on clock or file system or database or web services or anything outside the function under test disqualifies your test as a microtest.
- Don't try to test the unit in context; this way lies trouble. Test it in artificial context.
- Don't build a bigger framework for testing; make a smaller test.
- You have to know what is the micro-unit of code you're trying to test.
- TDD is not slow. It just seems like it is going to be slow.
- You don't have to read the code to understand a good test.
- TDD is a specific discipline. It can be done wrong or badly.
- Tests have their own anti-patterns.
Visit They're Called Microtests by Mike Hill, and then maybe consider learning more at Industrial Logic.
Post a Comment