TDDaiYMI XPManchester
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.
-
Follow
Following
Already have a WordPress.com account? Log in now.
cumulativehypotheses 
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: https://github.com/stephutch/Misc-Haskell-/
Stephen Hutchinson
April 18, 2016 at 5:49 pm
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!
ryanwgough
April 21, 2016 at 10:00 pm
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: https://github.com/claresudbery/BowlingGameKata.
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…
claresudbery
May 5, 2016 at 6:32 pm