On Friday 11th September, I was at Code Craft Conf (@codecraftuk) in Glasgow facilitating a Guided Conversation on Test Driven Development. It was a great event and I hope it becomes a regular fixture in the calendar. Many thanks to the organisers.

Here are the 12 questions I planned. We didn’t get through them all, but we did have many entertaining discussions over the session:

* Why do we test/why do we test first ?
* Where does TDD add “value” ?
* How does test “value” vary over time ? (life-cycle from writing test first to it becoming part of the regression pack)
* When is TDD not appropriate ?
* What’s are the qualities of a good test ?
* Do you have to be strict about test types? Unit vs. Collaboration vs. Integration etc.
* What is the hardest things about TDD ?
* How do you determine the right ratio of test types ?
* Do you care about code coverage ?
* What stops you/others from practicing TDD ?
* Does TDD have an effect on team dynamics ?
* Can you prove that TDD delivers software more effectively than other methods ? (soliciting real stories & comparing “war stories”)

I’d be interested in your thoughts on any of them…might even motivate me to blog more ūüėČ

Advertisements

My friend and colleague Wayne Grant¬†posted an excellent blog/summary of his experiences at Lean Agile Scotland 2012. I was there too and this spurred me on to finish writing about what I got out of the conference too. I’m trying to describe the thoughts I had about some of the talks rather than summarising the content (if you want a summary of the content, check out the Schedule on the link to the conference above), so please let me know if you think I’ve completely missed the point on any of them.

TDD

Common Objections to TDD
As I’m running TDD workshops myself, I felt that I had to attend the two TDD talks just in case I was missing out on any new thinking on the subject. First up was Seb Rose (@sebrose) with¬†Common Objections to TDD (and their¬†refutations). Seb had run a survey on the web gathering objections to TDD and this was an entertaining walk through them followed by discussion of why it was or wasn’t a valid one.

I found it very interesting in Seb’s results, that of the teams claiming to “be agile”, only about half were¬†using¬†TDD. I consider TDD to be core practice and apply the principle to many things outside of software development too as it brings me focus, forces me to ensure I have a good understanding of the task at hand, and provides a measurement of success afterwards. For example, if I’m about to make a phone call I often think of a test-case to describe the call:

  • My car will be booked into the garage…or my team will get to work on a new project

This sets me up for the call and during the call I can refer to it to make sure that it’s moving in the right direction or if I’ve become distracted/side-tracked, I can steer it back around. When the call is over I have a very simple check to see if it was a successful call or not. Maybe I take these things too far, but it works for me as I’m easily distracted.

TDD Pitfalls

The second talk on TDD was Brian Swan (@bgswan) with TDD Pitfalls. I’ve know Brian for some time and didn’t think there would be too much contentious material in his talk but I was motivated to question “Tests as Documentation” as a pitfall.

I don’t like comments in code for a number of reasons, but the biggest one is that they are always out of date. Well, that’s not true…but it very quickly becomes the case in a changing code-base and there is no easy way to tell, so I assume they are…and more often than not, delete them. For me, when I want to understand what a class does and how it should behave, I always read the tests first and find good value in that when they are written well.

I think what Brian was getting at in his talk was that it is very hard to write tests that clearly ¬†describe the¬†behaviour¬†of the class…and forcing yourself to do that is the pitfall, and I’m thinking that he might have a point. It’s very easy to expend a lot of effort trying to achieve this and when you look at the code you still, eventually (I’ll still read the tests first) end up reading the implementation.

BDD

BDD: Busting the Myths

Related to TDD, there was BDD: Busting The Myths with¬†Gojko Adzic (@gojkoadzic)…and if there’s an award for most entertaining talk of the conference, Gojko wins it easily. My exposure to BDD has always been at arms length and been dominated by people showing off how clever the tools are. I’ve never been convinced of it’s value because of this exposure, but have always felt that I was writing off something that could be¬†immensely¬†valuable.

What I took away from this talk was that, as I’d suspected, the tool was just a distraction. BDD is all about facilitating the conversation between the customer and the¬†implementer. That there are some tools to capture this is merely a convenience and I don’t think we’ll ever get to the state where the customer can just turn up with a set of BDD tests (am I even allowed to call them tests?) to hand to a development team.

The conversation is where all the knowledge about the work/story/feature comes from and BDD tests are used to steer that in much a similar way as TDD focuses code and makes you ask the questions around behaviours.

The big revelation I had was that these BDD tests have a much shorter shelf-life than I had imagined. While talking about the costs of maintaining large BDD suites, Gojko was discouraging their use for regression testing of applications (well, certainly using them verbatim as the regression test). I had always struggled to imagine the customer truly owning the tests and maintaining and updating hundreds of them over the life of the product. By suggesting that the most value for them is in the initial implementation and perhaps not maintaining them further down the line seemed to make them much clearer and usable/well defined in my head.

End of Part 1

So that was Part 1, I hope it wasn’t too rambling and that perhaps you even found it interesting. In Part 2 I’ll be talking about People, Kanban, and Rightshifting and some new things I’d like my team to try out.