TL;DR

On Thursday, the 4th day of my conference learning path was the first conference day. Let’s start with opening keynote story by Mirjam Bäuerlein – Treat yourself – a tale about dog training and test-driven development.

Hi #EuroTestConf 👋 I uploaded the slides from my keynote yesterday. You can find the code examples on github. Did a commit with every test-code-step so you can follow along the process starting with the fist commit.
Code: https://t.co/bh3QYlHNsD
Slides: https://t.co/jnbHw9LGu2

— Mirjam (@mirjam_diala) February 7, 2020

Here are my learning takeaways from this keynote.

This was my first contact with a live example of how TDD should look like. Previously, I have just read about this. From test that will fail because there is no code, to Mirjam thinking thread how she transforms user story to live code using the test for her code design decisions.

But first, let’s explain the business domain that she TDD into production code. She is a developer at Bryter. Before that, she was a dog trainer for nine years. This was her example in the keynote. She is also involved with Conference Buddy, an application that is for everyone afraid to go to the tech conference alone.

How To Train A Dog?

When you train dogs, you are in BEHAVIOUR business. Your goal is to replace unwanted dog behavior for the desired one in a real-life situation. When a dog barks, this is its behavior. We need to replace that behavior with the desired one, and if we succeed, we treat a dog with Dog desired reward. This is a positive reinforcement technique. Petting a dog to his head is not Dog desired reward.

After that first step, you repeat the desired behavior, and for that, we need a detailed description of how the desired behavior should look like.

The user story represents our goal. While we define our user stories, remember to start with small steps (scope). For example, that would be a dog walk with just five steps in the backyard of your house.

TDD

TDD cycle is

RED => GREEN => REFACTOR (code and test)

That cycle we repeat and cycle scope is a small part of a feature. Question is what is a small part of a feature. Mirjam is going to show us in a live coding presentation. We are creating a dog training simulator in javascript. We first implement the following user story:

Touch => say the word => show two fingers => Dog touches with nose two fingers.

And this is the first acceptance criteria:

When we say word touch to our Dog, and we show middle and pointer fingers together, the Dog should touch those fingers with its nose.

We need to set training simulator initial state:

• no past and no conditions
• reward, neutral and punishment actions
• visible dog reactions to consequences

Mirjam starts with a test that fails. In that test, she tries to initialize a class Dog, that does not exist yet. In that first test, she decided that the class name is Dog, and that is the value of that first test.

For the rest of magic, the best is to explore commits from GitHub repo in the above Tweet. Each commit is a small step, and that commit must not be about the final solution in mind.

My stand is that while doing TDD we need to follow basic TDD rules, but the final outcome of TDD steps would be not unique for all developers. And that is the beauty of software development.

At the end of the presentation, Mirjam gave two advice on how testers could help developers:

• create a balanced test pyramid
• think about “nasty” edge cases

Here are Marianne Duijst (@marianneduijst) sketchnotes on opening keynote: