Filed under: BDD, Presentation, Selenium, — Tags: Behaviour-Driven Development, The four rules of simple design — Thomas Sundberg — 2018-05-20
In june 2018 I will return to I T.A.K.E. Unconference in Bucharest, Romania. I run two sessions there:
These two sessions combine something I think is very important. They combine clean and understandable code with discovering what to implement. Understanding what to do is often more valuable than to know how to implement something. Implementing the wrong solution may even be harmful and is just as much waste as implementing something wrong.
This session is all about understanding what we should implement. A user story may seem complete and easy to understand until you start to implement it. It is very common that something that looks easy to understand contains ambiguity. Or just means different thing for different persons and perspectives.
Developers and testers may have lots of questions that need to be answered before development can begin.
We will practice on creating concrete examples from a user story. We will use pen, paper and a structured conversation to examine a user story. If it is easy to understand it is possible that we can find a few examples that fully describes it. If it is hard to understand we will find things that need clarification. This technique can be used to split user stories as well as exploring the problem deeper.
It was first described by Matt Wynne in a blog post back in 2015.
As a developer who deeply cares about code quality it is a pleasure to take a code sample, apply some seemingly simple rules on it and transform it into something better.
The four rules of simple design can be described like this:
They seem simple, they are simple, but it is hard work to really understand and implement them. I blogged about them a few years ago when I first heard of them at a code retreat in Krakow.
In this session, I will apply the four rules step by step and transform something ugly into something better. It will be a live coding session.
These two topics are an important part of the larger topic Test automation. It is something a lot of developers work hard with. But I still see, in 2018, many developers who don't bother with driving their development using automated tests. From one perspective it saddens me, from another perspective it guarantees that my services as a consultant and teacher still is needed.
RSS