Software Cornwall TDD Workshop Learnings

Peter Conway

Peter studied Theoretical Physics at Swansea University and once had ambitions to go into particle physics. Since graduating he has completed a software development apprenticeship and worked as a data scientist and machine learning engineer before coming to Headforwards about a year ago. He has become interested in Agile, best development practices, testing, and business processes since starting at Headforwards, inspired by reading books suggested by other members of the team: The Unicorn Project, Joy Inc., and most recently Exponential Organizations. Outside work he loves staying fit. He is an avid runner, casual football player, and recently started maintaining an allotment.

A four day workshop focusing on test driven development hosted by Jon Jagger and Kevlin Henney

Last week I was fortunate enough to be given the opportunity to attend Software Cornwall’s TDD workshop being run by Jon Jagger and Kevlin Henney. I learned a huge amount about testing and would be happy to do a more exhaustive write-up of the course if people are interested. What I’ll share here are some little gems of knowledge that were shared between the exercises and lectures that the week comprised of, often in response to difficult questions posed by other listeners.

Different conventions for tests and code is okay

Whatever language you're using to solve a particular problem will have its own set of conventions. This could be a particular case that variables are written in, or a preferred way to access the elements in an array. Naturally, when writing our tests, these conventions tend to follow us. Jon and Kevlin wanted to make it clear that this needn't be the case. Like a letter and a shopping list might have different linguistic and structural conventions, so can tests and code. Your priority should always be clarity and communication.

Unqualified imports [Python] are fine, the tests are the centre of the universe

Tests should do more than just poke the software. They should also communicate thoughts & ideas

Tests should reinterpret the requirements

Context: it’s okay to repeat requirements verbatim in tests, because it helps explain your understanding.

An analogy was made to dancing, where you could lead with either foot (tests or code) but big strides in either are bad. One very helpful way to think about complexity they used was the number of calories required to understand code and tests. This could be through literally looking up and down code to find functions, or because there are poorly named variables that require you to explicitly understand what’s happening.

Avoid drive-by assertions in tests, a Given-When-Then [or equivalent] structure is preferable

It’s hard to see problems when you’re moving fast. Slow down enough to look

Context: taken from Austin Kleon’s book Keep Going, written to help creative people stay creative.

Single-use functions are fine if they reveal intent

The last one might be my favourite. A justification for something that sometimes feels a little uncomfortable brings a great relief. The example problems on cyber-dojo.org, which are small by design, can highlight problems usually associated with large code bases in as little as thirty minutes. I've found the process of analysing these problems to be very beneficial, which is why I'm going to try to get into the habit of solving one problem per week to keep my skills sharp and continue to improve my approach to writing code and tests.

Probably the single most useful thing I learned was the concept of burning calories to understand code or tests. It's an abstract way to measure complexity, you could burn calories by literally looking up and down code to find functions, or burn calories by using your brain to understand some particularly complicated or poorly explained test.

If any of you get the opportunity to attend a course or lecture given by Jon Jagger or Kevlin Henney I'd strongly suggest you check it out. They made an effort to tailor the course towards things people specifically mentioned they'd like to learn.

Thanks for allowing me to attend and thanks for reading!

About the Trainers

Kevlin Henney

Kevlin is an independent consultant, speaker, writer and trainer. His development interests are in patterns, programming, practice and process. He has been a columnist for a number of magazines and sites and has been on far too many committees (it has been said that "a committee is a cul-de-sac down which ideas are lured and then quietly strangled"). He is co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series. He is also editor of 97 Things Every Programmer Should Know. He lives in Bristol and online.

Jon Jagger

Jon is a software consultant specialising in practice, process, test driven development and complex-adaptive systems thinking. He's 35 years old (hex) and has loved software since he was 10 (decimal). He built cyber-dojo.org to promote deliberate practice for software developers. Jon has worked with Accenture, Aviva, Cisco, Ericsson, Friends Provident, HP, Microsoft, Opera, Ordnance Survey, RBS, Reuters, Renault F1, Schlumberger, Tandberg and many many more. He's the co-author (with Olve Maudal) of the Deep C/C++ slide deck (over 1 million views) and has had some C# books published.

COVID-19

The health of our team along with business continuity are our priorities at this time. Our teams are now working from home and continuing with projects as normal.

All phones and emails are being monitored as usual so if you have an enquiry or any questions, please get in touch.