Kafka - TDD - And a course in TDD with Roy Osherove

I just finished a 3-day TDD course with Roy Osherove. Here are some of my lessons.

"The right understanding of any matter and a misunderstanding of the same matter do not wholly exclude each other", Kafka. That is one of the ultimate issues with software development, and TDD helps addressing it. How?

The simple rules for TDD are:

1. Write a test that fails.
2. Make the test pass.
3. Refactor.

By following these rules I will also do:

• Investigate the problem domain, but not more than necessary, and make sure the assumptions are right.
• Implement code that works.
• Implement the right code.
• Start with a simple thing, that can be finished within short time, at least within a sprint.
• The development cycle will have small incremental changes, rather than larger code chunks which is harder to test.
• Decide when to do state-based testing and when to do interaction-testing.
• Do test reviews.

Other things I will do:

• Address legacy code with TDD.
• Consider not doing TDD, but right now TDD feels simpler than not doing TDD. Even though TDD is hard.
• Separate unit tests and integration tests.
• Do pair programming.
• Write more integration tests.
• Start learning code contracts (C# 4.0).
• Start learning specification by example and write acceptance tests.
• When I have made a new system, or learned a legacy system, I will make a video describing it
• Write down the coding conventions.

Other things I learned from Roy:

• How to learn things, and what ravines and plateaus are. (This is a part I feel need even more investigation, but not now.)
• Go mouse-less.
• Do coding katas for training. (I have already been doing this after the course, and will continue).

So TDD addresses the understanding/misunderstanding of issues by forcing you to make assumptions and implement the right code. Make it your choice to do it!