Dapeng Li

Hungry, foolish and passionate – yet another software developer.

Archive for the ‘TDD’ tag

Things I learned from Kent Beck’s TDD screencasts

leave a comment

Recently I watched the screencasts by Kent Beck on Test-Driven Development (TDD).

Being glad to see I had been doing TDD similar to Kent, I learned quite something from the screencasts. Although my notes are just bullet points here and there, neither comprehensive nor introductory, I believe they can be of value to programmers and would like to share with you in this post.

Top-down or bottom-up

When adding tests and features, you can go with the top-down or bottom-up approaches.

  • Top-down: write code calling the non-existent method, create the method stub, implement and make the test pass.
  • Bottom-up: with some kind of implementation, extract part of it as a method and invoke that method. This is refactoring, build something then break it down into pieces.

Isolated tests

Tests should be isolated, means they should be able to run on their own, without affecting others. Kent puts clean-up code after the test methods.

Isolated here is not about dependency injection or faking, which is very important in TDD, but unfortunately Kent’s screencasts didn’t cover it.

Prediction game

Predict if the test will succeed or fail before running it, this way you are more engaged and not just programming by coincidence.

Finer grain tests as scaffolding

When it’s not green (there are failing tests) for a method, it’s OK to write finer grain tests to test the helper methods to be used by that method.

So at some point, you will have multiple tests failing, and you fix the finer grain tests first.

Those smaller tests can be considered scaffolding, if later you decide the helper methods should not be publicly accesible, it’s OK to delete those scaffolding tests.

“Yes” is an expense, “No” is a risk

Kent thinks carefully about whether to write the test for a method.

To quote (paraphrased from his summary in the screencast):

Every test is an expense, short and long term, it needs to pay back in Informational or Emotional Feedback; on the other hand, every test that you don’t write is a risk.

Interestingly, Kent plays a betting game with himself about that. I suggest you watch the screencasts and find it out.

Generalizing TDD

Kent generalizes the approach in TDD, the problem-development-cleanup cycle, to a larger context. He argues that this is not only the way we do TDD with a method (for a couple of minutes), but also how we implement some features (maybe for about 30 minutes, the length of one episode of his screencasts), how we solve a larger problem (for days, weeks, or longer).

I agree with him. Begin with the end in mind, seek short feedback loops, and review, that is how we solve problems. It seems so natural and simple, yet TDD – which applies this approach in a micro level – is so powerful however strange it seems when being first encountered.

Practice, practice, practice

Kent practices TDD on the same problem again and again. It goes like this: write some code, erase it, write in a different order, erase it, until it’s efficient and gives a lot of feedback.

This reminds me of the code kata and Chad Fowler’s book.

I would like to finish with a quote from Kent:

I’m not a great programmer; I’m just a good programmer with great habits.

Kent, thank you for the sharing and ispiration.

Written by Dapeng

January 3rd, 2015 at 6:46 pm

Posted in Programming

Tagged with