Podcast Released: TDD Guided by ZOMBIES with James Grenning

#1

tdd guided by zombies.png700×350 137 KB

[Listen Here]

This podcast is brought to you by Scrum Gathering Canada. Learn more at scrumgathering.ca

We are joined by James Grenning, co-author of the agile manifesto, this week. James joins to discuss his training framework for Test Driven Development; TDD Guided by Zombies. James sits with Ryan Lockard and discusses unit testing, TDD and how both apply to his ZOMBIE paradigm.

Please consider subscribing to our show to hear more content like this. We also welcome and encourage your feedback via email or on our free network, coalition.agileuprising.com. Please also consider leaving a positive review for the show on iTunes or Stitcher

Various links from the show:

James’ book: Test Driven Development for Embedded C
James’ training offerings
Tim Ottinger on twitter: @tottinge
@asciamanna’s post: TDD is not a Testing Practice
Untappd – Social network for craft beer drinkers
James on Untappd; jwgrenning

Hey, the place to be next Spring is Canada. Our friends up north are throwing a party – a Scrum Gathering, to be exact. Get yourselves to Toronto for March 26 & 27 and enjoy some fun with the exchange rate! Register, sponsor, or submit a session proposal at scrumgathering.ca (scrum gathering dot c a). The gathering will be in the heart of downtown Toronto, the nearest airports are YTZ and YYZ. Also, a special discount is available to all listeners of our podcast. Use the discount code, “uprising” – all lower case, to get 15% off the regular price of the gathering.

#2

This is another great podcast with James Grenning! As I was listening to it I was reminded of a blog post by Uncle Bob Martin from a few years ago. James describes thinking about any missing tests for error conditions and exceptional cases (the ‘E’ in ZOMBIES) as you are wrapping up the tests for the functionality.

Uncle Bob describes a technique when practicing TDD where you focus on the unit tests for exceptional cases and error conditions first before writing tests for the functionality:
Thorns around the Gold - Uncle Bob Martin

#3

Interesting distinction to reflect on. James and Uncle Bob seem to be using “exceptional” slightly differently.

I think my own practice is driven by whether I consider a case to be in or out of the contract for the class. I start with the simplest cases that fall within the contract (empty inputs, maybe nulls, etc.), then proceed to more interesting cases that flesh out the contract. Only then do I worry about how the code handles cases outside its contract, such as malformed inputs, and often I don’t bother if the code in question isn’t a public API of the system.

Some cases that Uncle Bob calls “exceptional”, such as deleting an element that doesn’t exist or adding a duplicate element, don’t sound so “exceptional” to me – they’re interesting cases within the contract, but not the simplest ones, and therefore feel like “grabbing for the gold” if I do them first.

And some cases that he calls “exceptional” seem potentially quite hairy, and therefore inappropriate to start with, since handling them nicely can often get complicated – e.g. giving a nice diagnostic error message may require parsing as much of the input as possible, which can be much more complicated than parsing the input assuming there are no errors.

#4

I agree with your assessment. I think Uncle Bob and James are actually giving some similar advice just their definition of “exceptional” may be different. Some of Uncle Bob’s exceptional cases may fall into the “zero case” that James describes.

Also +1 for not validating input if it’s not a public API. I often see developers validate the same inputs over and over and in a lot of those cases the validation and error handling is unreachable because the inputs in question have already been validated in a different layer.