mostly professional blather

TDDaiYMI XPManchester

with 3 comments

Please report on your experience with the session in comments to this post. And, if you’re happy to, please post a link to your code.

Written by keithb

April 14, 2016 at 4:36 pm

Posted in Uncategorized

3 Responses

Subscribe to comments with RSS.

  1. Excellent Session. I bottled out of doing it in Haskell on the night, but had a go at doing it in my own time later. The results as a sequence of files to which I’ve added a commentary are here:

    Stephen Hutchinson

    April 18, 2016 at 5:49 pm

  2. Really enjoyed the session, though must admit found it really tough. I would post the code I wrote but as I was only on the second test there seems little point! I have tried the excercise again and still found it very difficult not to make a “leap of imagination” towards the solution without being driven by the tests / problem!

    One really nice takeaway were the little heuristics around the number of tests vs possible states of the system and the implications around how we choose to represent state – i.e. not strings!


    April 21, 2016 at 10:00 pm

  3. I was quite tired on the night in question and didn’t quite get it, but I ran through it with a colleague (@garymcleanhall) last week and it suddenly clicked! What confused me was that I didn’t quite understand what was meant by writing functional code within the test itself. If the test was testing code that only existed within the test, then surely it wasn’t testing anything other than itself?

    Gary and I spent less than an hour on it, so we didn’t technically made much progress, but we did reach a point where I understood the general principle, and how further progress would be made. The code we wrote is available here:

    The tipping point for me was when I realised why it is fine to have a test which simply creates a variable and then instantly checks its value: A later test will inevitably create a similar variable and also check its value. At this point you have duplication, so you create a separate method within the test class. Now you have two tests referencing the same code. The more tests you write, the more of this code you have, until you reach a point where it makes sense to move that code into a separate class… and NOW you have the beginnings of a domain design which has been driven by the tests.

    The alternative is to create a domain object in response to your first test (for instance, I wanted to create a Game object, with a Try method, and a Score property). The problem with this is that you are coming up with a design before your test has rendered it necessary.

    My colleague Gary likes to make the important distinction between “test driven” development – which this most certainly is, and “test first” development, which is what most of us do most of the time. His argument though, is that for day-to-day dev work, which is rarely greenfield and more commonly maintenance, the “test first” approach is a good fit.

    I’m hoping to write a blog post on this, on our Laterooms company blog, very soon…


    May 5, 2016 at 6:32 pm

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 )

Facebook photo

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

Connecting to %s

%d bloggers like this: