Tag Archives: ATDD

Principles of ATDD: Single Responsibility Principle

The other day, I sat down Kishen Simbhoedatpanday in order to talk about ATDD, and eventually an upcoming class on the implementation side of ATDD. We talked about maintainable tests, and how you could refactor tests to yield better tests. Gojko wrote about the anatomy of a good acceptance test a while back, and I think we can be more explicit here. Then it struck me. The Single Responsibility Principle also applies to your automated examples – and why that’s the case. You just need to think on a conceptual level about it. Mixing business domain concerns with application concerns in your examples – and sometimes even with driver concerns (think Selenium) – is a terrible thing to do.

Let’s explore this idea further.

Continue reading Principles of ATDD: Single Responsibility Principle

ATDD in scaled agile environments

Years ago, I wrote a book on ATDD. Only years later I notice the value that this practice can bring to an environment with multiple teams working together on the same platform. The connection to scaling agile in the larger enterprise wasn’t that obvious than it became when I started to dive deeper into how to scale agile. Though, most larger enterprise struggle with getting one team running, scaling has become the latest fuzz in the agile community. Let’s see why ATDD is relevant for this sort of environment, and how you can challenge your team colleagues about it.

Continue reading ATDD in scaled agile environments

Maintainable automated tests – the architecture view

When it comes to functional test automation, most legacy application have to deal with the problem, that retro-fitting automated tests to an application that was not built with it from scratch, can be painful. In the long-run, teams may face one problem. The automated tests constrain further development on the production software. The tests are highly coupled to the software that they test. Let’s see how we can solve these problems with a clear architecture in the beginning of our automation journey.

Continue reading Maintainable automated tests – the architecture view

Coderetreat goes testautomation

I remember a talk from Cory Foy back at XP 2010 in Trondheim, Norway. He referred to Corey Haines as the happiest guy in the world. Although he lost his job, he started to travel around in the world, from shop to shop, from company to company. He was able to learn so much in a single year that he continued his journeyman tour after that.

One thing that Corey Haines invented alongside is a Coderetreat. Up until the global day of Coderetreat last year on 3rd of December I didn’t know what a Coderetreat actually is. At the core are six sessions of 45 minutes each where you solve a problem in code. Then you delete your code, and do it again – maybe with a different pair partner.

Recently J.B. Rainsberger invented the idea of a Legacy Coderetreat. The idea there is similar to a Coderetreat, but have to deal with legacy code and improve it. I attended one Legacy Coderetreat in the mean time, and it was quite interesting to solve the problem of a big mess of code.

At some point back last year I got in touch with Corey Haines and Adam Goucher. We bounced some ideas back an forth, and I refined them later with Adrian Bolboaca to yield a Coderetreat for testautomation code. Now I am happy to announce the first Testautomation Coderetreat in Munich on June 2nd.

Continue reading Coderetreat goes testautomation

On the PageObject Pattern

Recently I started to think more in depth about the PageObject pattern – at least how some folks called it initially. One problem I noticed in discussion with colleagues and clients is the lack of pattern description for this so called pattern. I decided to explore this problem in more depth, and try to come up with a constructive solution to that problem.

Continue reading On the PageObject Pattern

On Programmer-Tester separation

One of the things that testers in my classes on ATDD and Exploratory Testing struggle the most with is that programmers and testers appear to give up independence with this approach. My first reaction to this is often that I hear them asking to leave their testing silos in place, and start to convince them to collaborate more with the programmers. By hard I recently learned that the Helpful Model (“No matter how it looks, everyone is trying to be helpful.” Secrets of Consulting, page 101) and the Rule of Three Interpretations (“If I can’t think of at least three different interpretations of what I received, I haven’t thought enough about what it might mean.”, Quality Software Management Volume 2 First-order measurement, page 90) also applies to myself.

Continue reading On Programmer-Tester separation

Teaching from the back of the room

During the last week I made some experiences using the material form the Accelerated Learning method. Motivated from the enthusiasm from my colleagues Stefan Roock and Henning Wolf, I read the book from Sharon Bowman about Training from the BACK of the room! The insights I got from reading it are great, and I was lucky enough to immediately apply them during training courses over the past week. Here are my findings about it, what I did, and what I might do in the future with the insights I got.

Continue reading Teaching from the back of the room