This blog entry is a follow-up answer I got after my tutorial session on ATDD/BDD at the recent SoCraTes conference in Soltau, Germany (YAY! We’re back to conferring in person!) After showing the participants how I struggle with a new (to me) ATDD/BDD testing framework, raw and unscripted, alongside answering questions raised by the attending participants, one person approached me with a question that I could not answer on the spot directly since I needed a break. Although I offered to get back to me later during the conference days, we never got to chat again. Maybe this might be of some help to others.
All that said, the question raised as I recall understanding it was something like this:
How would you test an application on the user interface? We have this old application, pretty old, and we just seem able to hook examples exemplifying business rules by going through the GUI.
My elobarate answer(s) and perspective(s) are the following.
Continue reading Follow-up on: How do you automate tests through the GUI?
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
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
When it comes to ATDD, people, teams, and companies usually put the wrong emphasize on the elements. This blog entry is going to explore the relevant areas for successful ATDD, and how to overcome some of the misconceptions about it.
Continue reading Setting the right focus when getting started with ATDD
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
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
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
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
On February 2nd 2011 I was invited by Gojko Adzic to a seminar on Winning Big with Specification by Example. It was a half day seminar that took place in London. This is what I took away from the course.
Continue reading Specification by Example – The Big Win