Sydney testers meetup #37 – Journey of Acceptance Test Driven Development #Sydtest
This is the official blog post of Sydney Testers meetup on ATDD.
The meetup was held at the Orient hotel in the rocks, and the place was pretty full. I thought I was smart to take a seat in a couch in the back, but the open window (non-closable) made my fingers stiff and body shaking throughout. =(
Evening kicked off with some networking and a beer, followed by opening notes with club news and testing news. I particularly like the short testing news highlights. Don’t forget to follow up on the highlights!
The Presentation – Journey of Acceptance test driven development
Devesh and Priank told us about Acceptance Test Driven Development, ATDD (slides here). All in all, the presentation was a good mix of technical/practical aspects of ATDD and the more in-depth understanding of why its a good practice for collaboration and shared understanding. The guys know what they are doing in their work, but capturing the most important parts into a 50 minute presentation is not easy. But they kept the crowd engaged and got good questions that they answered very well.
The name ATDD can be hard to grasp or accept, and that is usually caused by the acceptance test part. They mentioned it later in their presentation, but I would like to point out already, that ATDD is pretty much the same as BDD and Specification by Example, they are all example based models for specifications. Also, there are problems calling them acceptance tests, as the notion of rejection checks is a better term in general. There is also already some discussions going on in the meetup thread on this topic.
The presentation was going to start with what ATDD really is (according to their own agenda), but they started off with some slides on why projects fail. Surely there are plenty of reasons for that, but for me that was kind of like selling ATDD as the silver bullet, it is not! Sure, projects are more prone to succeeding with good collaboration and communication, and ATDD can help with that, but that’s where I would stop suggesting ATDD for not getting failed projects.
Then we got to know how ATDD and TDD work together, TDD solving the “Are we building the product right” and ATDD solving “Are we building the right product.” While these statements might have some connection here, I would rather not see TDD and ATDD being referenced as equivalents of validation and verification that traditionally are tied to these sentences.
They continued by saying that the most important parts of ATDD were really the conversations and ways tog get shared understanding of the product between stakeholders. I completely agree here, and I would actually have wanted them to continue with this bit a little more. The end of the presentation had plenty of great gotchas for benefits, challenges and anti-patterns for ATDD, but unfortunately these bits were cut short because of time. Be sure to check those slides.
Instead, we got to see some live code examples of scenarios running cucumber in an example with webdriver. We also got to see them run off a live test suite from a current project of theirs. This is a nice way of showing off some of the technical aspect of the practice. The example of the web form was also good to see how to actually write the examples sensibly.
However, the automation is also a way to easy alienate parts of the audience that 1, is not technical enough and 2, that dont have any web ui in their product contexts. Anyway, examples like this do have a pedagogical way of showing off the concepts for better understanding, so they are valid in this broad intro session on ATDD. But it is really important to remember that the type of automation one wants out of ATDD in their project need to have plenty of context considerations before adding all those layers of UI testing. The simple code examples can be found here.
There was also a section on how to create good acceptance tests by making them SMART, however this is something usually referred to when talking about SMART goals or objectives. I cannot find references to SMART acceptance tests, so I would like to get that clarified.
I think the presentation was worthwhile, and i am happy I took the time to go. I picked up some new things, like the poltergeist headless browser. But it should also be said that it was an introduction to ATDD, so having heard about it many times, no new things were really covered. As we have a very diverse crowd of both test managers and non-technical folks, I think many people at the meetup had also never heard of it.
My 50 cents on ATDD
Naming – I use the three names ATDD, BDD, Specification by example interchangeably, as I have seen benefits of the different names in different contexts. Although it is important to note that the three have different background and differ slightly.
Cucumber/Gherkin is a nice tool for the living documentation, and there are plenty of implementations of it for different languages and fixtures.
If you dont have any business stakeholders valuing the gherking specifications, they might just be a waste in terms of yet another abstraction layer to maintain. I have seen projects that just as well name their Junit methods in a good way without having the extra layers.
Don’t ever think that ATDD/BDD/SBE is the silver bullet for any quality issues you might have in your product or project. Use it as a tool for communication and complement with other types of testing related activities as well.
These were the links provided at the end of the presentation: