Thoughts about TDD

Thoughts and links about test driven development

First a disclaimer: I think tests are a hallmark for professional software development, I like to write tests before the implementation but that’s not always easy or simple (for the difference please refer to Simple made easy). I find it hard to grasp test driven development (TDD) though. The difference between test first and test driven lies in the intention: in both cases tests are written before any implementation code but in TDD the tests drive the design of your implementation.

The problem with opinions of TDD is there are mostly extreme positions: some think “TDD is the (next) holy grail” or the ones which dismissed it. Though reading between the lines there are great discussions about how to do it and what problems arise. Many people (me included) are really trying to get value from TDD. Testing should be fun.
One way in letting the tests drive the way you develop is proposed by Uncle Bob: transformation priority premise. He proposes a list of transformations which introduce new or replace existing constructs like replacing a constant by a variable or adding more logic and gives them a priority. Only if you cannot use a high priority transformation to get the test to pass you look at a transformation with a lower priority.
But how do you determine what you should test next or even which is the first test?
Taking the typical Conway’s game of life kata as an example one thing struck me: I could only get the TDD to work smoothly when I started with the data structure. But why that? Naturally I start with the algorithm (in this case the rules) and write the first test for it. But upon further inspection of the problem and deeper (domain) knowledge it seems the data structure is way more important for solving this kata. So you need to know where the journey goes along beforehand, not every step you will take but the big picture: first the data structure, then the rules in this example. Maybe you should start with the integrations or the functional tests and break them down into units.
What are your experiences using TDD? Do you use or want to use TDD?

One thought on “Thoughts about TDD”

  1. Hi, Jens.

    I would say from my experience that TDD is really dependent upon the environment, namely:
    – which language do you use (i.e., in scripting/dynamic language the need for TDD is higher, as compared to statitically typed language, as Scala). As well, it is much more harder to do TDD in C++ (as the length of compile/run cycle is bigger)
    – secondly, TDD is a great way that forces thinking, but it should be done correctly:
    – this mean not to overdo with way too many test (remember, tests are the way to reduce risks)
    – not trying to write all tests in advance, but having only one\two failing tests, on the base of which code is to be extended
    – thirdly, it really depends from problem domain.
    Gerard Meszaros has a scale of difficulty of writing tests, and for some areas (example – legacy, asynchornous, GUI) it is really harder to write tests. As well, for GUI not all things are worth testing (example – it could be worse testing, whether some buttons are enabled/disabled in certain conditions, but usually less worse to test the layout of the dialog.)

    As well, on the base of my experience, TDD could be used to develop algorithms, but you would get in this way functionally correct algorithm, but not necessary performant one.
    Therefore, TDD could not be used for selecting proper data structure/algorithm for solving a problen.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.