Dear BDD Addicts,

For the IT industry, autumn is like Christmas for retailers. People are back from holidays, new projects get started, everyone focuses on the Q3 releases. And there are a lot of interesting conferences too to boost up your knowledge.

In this month collection, I’ve tried to select articles that can help you to review and improve your development process. It is going to be a busy season, so let’s dive into the middle and see our dose.

---

[Agile] Agile is not “done”

I’ve stumbled on Alistair Cockburn’s recent articles on the status of agile. This seems to be an important question for many of us, because we see that agile has become “well-known”, but also we see many broken agile adoptions. What will happen next? Some people even talk about the death of agile, but can we really talk about its death? These are the questions that the articles try to answer. Pretty interesting read!

What happens after Agile crosses the chasm  (part 2) (Alistair Cockburn, @TotherAlistair)

---

[BDD] Example-guided development

Giving names to things is hard and even BDD suffers from this. The term Behaviour Driven Development was picked carefully to describe a collaborative approach that leads to better understanding and verification of the requirements. But there are other approaches with very similar goals, like Acceptance-Test Driven Development (ATDD) or Specification by Example (SbE). In some ways even Test-Driven Development (TDD) had the same goals. Are these different? Why do we have so many names? Would a new name be helpful? This is an open ended question that Matt Wynne has brought up recently. What do you think?

Example-guided development: A useful abstraction for the xDD family? (Matt Wynne, @mattwynne)

---

---

[BDD] Scenario refactoring: from bad to better

In the Formulation book with Seb Rose we have collected 6 principles for writing better BDD scenarios (we call them BRIEF principles). 6 principles do not seem to be too many, but for some of them you need a bit of practice to be able to apply them properly. Of course it is easier to write your scenarios “well” right from the beginning, but you can still clean up the exiting “bad” scenarios as well. It is even a good practice to better understand what the BRIEF principles are about.

Clean up bad BDD scenarios (Gaspar Nagy, @gasparnagy)

---

[Testing] Hard to apply TDD? Probably your code is not modular enough

Many people underestimate testability. They think that building up an automated test coverage for a feature would cost 100 (coins, days, coffees, dollars… you choose) without extra care and maybe I could make it in 80 if my code would be better testable. “Does it worth the effort? Maybe I’ll just make it better testable later, after the release.” That is quite off from reality. A better testable code can open up options that have not been possible before. It does not only help you to reduce the automation cost (to 10 or 20), but it can also reduce the implementation cost of the feature itself. Michael Feathers talks about this from the TDD point of view, but it is also applicable to many BDD automation solutions as well.

Unit tests are tests of modularity (Michael Feathers, @mfeathers)

---

---

[Automation] Page object model

The page object model has a pretty bad name and many people see it as a legacy old-school automation pattern. I think it is an important UI automation pattern that can help a lot. Of course it is not an ultimate solution and there are also extensions and alternatives to that as well, but still. And it also has the advantages of simplicity and popularity. So with the following post by James Walker, I would like to share a good “overview to concrete” kind of article about the page object pattern. As a bonus, the article also talks about the role of this pattern in agile development.

Agile Test Automation Frameworks Using Page Object Models (James Walker, linkedin:automationjames)