Hello craftspeople! This is Denis—I decided to split this stream’s recap into two parts as it came close to being 3 hours. Part One is Adrian and me going over the test desiderata and discussing qualities of tests and how it connects with TDD.
Part Two is when our audience members joined the hot seat and we explored writing different kinds of tests that emphasise different testing qualities.
Testing Qualities
We explored the test desiderata1 in the first hour. It’s a back-and-forth with Adrian discussing modern tooling and test runners for testing in general and with TDD practice in mind.
Today’s episode is to look into what are the qualities are good tests. It’s not specific to TDD, but it is about test automation, starting with unit (developer) tests
If you’re only interested in the test qualities bit, it starts at 15mins. I’m also writing a more detailed series on it which you can check here:
🧟 Z.O.M.B.I.E.S.
Jeff, one of our regulars highlighted his delight about following the zombies principle when writing tests in TDD style. We took a few moments to dig into it. Engineers that struggle with picking the right first tests and dig in straight to complexity can benefit from zombies.
James Grenning from Wingman Software coined the acronym ZOMBIES.
People new to TDD often struggle with what test to write. It’s hard to know where to start or what test to write next. It’s hard to know when you are done, and it’s scary to think you will leave some incomplete code behind. Scary! How can ZOMBIES help with scary?!
Z – Zero
O – One
M – Many (or More complex)
B – Boundary Behaviors
I – Interface definition
E – Exercise Exceptional behavior
S – Simple Scenarios, Simple Solutions
This method comes with a natural split at the ZOM- level. The boundary-behaviors of -BIES have a more outside-in feel to them, where the ZOM- is about detailed behavior.
To quote James from his blog2:
ZOMBIES is not your usual sequential acronym. It is only partially sequential. It has two dimensions. One Axis is ZOM[ZOM] the orthogonal axis if BIE, with simple test scenarios (several reasons for the S) bringing them together.
Thanks for reading,
—Denis
Tech Lead Coach, Mentor
Part 1: Structure Independent, behavior driven TDD