Natural language as code

A domain-specific language (DSL) is a computer language specialised to a particular application domain. This is in contrast to a general-purpose language (GPL), which is broadly applicable across domains, and lacks specialised features for a particular domain.

BDD !== Agile

BDD (Behaviour Driven Development) does struggle a little with Agile – why? Because as slick as Agile can be, it still panders to a closure mentality, ticking check-boxes as it goes along. A user story gets closed – BDD says “a what”? BDD very deliberately uses “Feature” terminology, encouraging as it does, focused and tangible deliverables, over the sometimes more-bloated User Story format. Both still are part of delivery, but in BDD, nothing is ever considered “Closed”, simply verified at a point in time. It is why BDD is frequently mentioned in context of Lean and Kanban – two other approaches that don’t fundamentally adhere to incremental closure. That is not to say BDD won’t work in any environment, but it can be a battle at the administration end, i.e. the life-cycle of requirements.

How many times I have heard the proclamation “we don’t need to regression test, we’re Agile” – missing the point that modern development approaches such as Continuous Integration (something else that doesn’t recognise closure) are by nature, regression testing. Regression testing is primarily about testing integration. As new features are added, there can always be unpredictable outcomes. You can mitigate this by regular checks, and effective development planning. BDD is also in the same area -it is not about finishing, it is about maintaining a continuum, which at some point will fulfil client requirements.

That does sound kinda casual, and it is a difficult sell. But the resulting product are more stable, feature-rich, and maintainable.

Its a big Given ….

BDD is an enjoyable way to develop and test, but introduce business and that pesky client, it can rapidly change into stressful Waterscrum or (the even worse) Scrummerfall.  Transparency is an easy word to throw out there, but who wants it?  No-one wants to hear bad news and show and tells rapidly descend into a perception game, to pander to client expectations of how development process works.  As with any engineering, most are shocked to learn that engineering is very much an incremental learning process, involving regular mistakes and learning exercises.

The average client expectation is still of having a tangible product, and not to be drawn into the more painful side of development process. It’s a two steps forward, one step back style process. And with BDD, even more so, as the business side is defining a lot more than just high level user stories – they are defining expectations on more granular level.  And in natural language.  Why the last point is very valid is that developers inherently have problems visualising the natural language of requirements in terms of code.  When in fact a scenario line could be viewed as a chunk of functional code.

When reviewing user stories, where the eyes should immediately be drawn to are the “Given” statements.  These generally can appear innocuous, but can hide a whole host of requirements upon development and QA.  Usually used to specify location, authentication and test data.  Test data itself can be a hugely underestimated task, and usually the specifications are wrapped up the the Given statements. Also smart to analyse any example tables for assumptions. It may look like innocuous input/output data, but it may be referencing part of a system that are not built yet, or have existing caveats.

BDD gives Agile a sledgehammer edge, and all the better for it – as long as you stay on top of the process, and can manage the client concerns over their over-exposure to the process.

 

BDD & Continuous Integration

BDD demands a lot of attention, and is definitely not for the faint-hearted.  Be prepared to have all your flaws exposed, and sometimes in ruthless succession. It is why I think more and more than Kanban style is the way forward in management of development, for two key reasons:-

1. Acceptance of concept of human error, and plans to mitigate that predictability.

2. Acceptance that plans made today may have to change tomorrow.

Continuous Integration (CI) is the part that is supposed to mitigate regression issues – that does not mean regression issues are not possible.It can be a single point of truth for the state of the application, if managed honestly.

A strange way to put it? Well …

One of the more ridiculous mantras of over-excited Agile developers, was that regression testing was dead, as the new development approach avoided the need for it.  Largely this assumption was made around increased use Continuous Integration, but comically, the mantra was still issued by those who didn’t observe CI principles.  CI practice can mitigate may regression issues, but it has to be GOOD practice.

A frequently standard CI setup involves many unit tests, testing code in isolation too often, instead of integration tests.  This presents a misleading picture of progress, as the actual benchmark of progress is at business logic level, not code level. Introduce your BDD tests into CI, and you can expect failures every single time, there is no such thing as 100% from an acceptance test point of view.  If it is, then the tests are not extensive enough or unit tests are too low level for any useful test results.

Management love hearing such positive reports “95% of our CI tests are passing”, without ever questioning what that actually means in terms of delivery. It could mean absolutely nothing, beyond verifying framework modules and/or code (that may or may not be relevant to requirements).

Lastly, there is no reason not to have more than one CI process running – one for unit tests, one for BDD tests.

BDD vs TDD

BDD – Lock the behaviour not the implementation

The example based on sorting sums up BDD testing perfectly (at 4:25).  The beauty of BDD is once you have your given‘s, when‘s and then‘s, you can start mixing up scenario statements to test different possible outcomes.  Or exploratory testing, if it needs a name.

How does BDD work?

Take a common scenario from end-user on a website. They are on the homepage and want to contact the company. So they click the Contact Us link and are presented a form to fill in. When processed this form will either submit details to the company email address or reject because the end-user has not completed all the fields OR made some error in form (for example the email field). This is a very common feature of most websites.

BDD: Is there a difference between programmer and tester?

To automate, you have to code. And if you are automating an application, the logical way to think about it is developing an application to test an application. And to do that from scratch – every time – would be laborious, and unnecessary as there are many common web features. This kind of thinking has been around in software development for decades – to program with reuse in mind.

BDD Myths

BDD

“Please call Stella. Ask her to bring these things with her from the store: six spoons of fresh snow peas, five thick slabs of blue cheese, and maybe a snack for her brother Bob. We also need a small plastic snake and a big toy frog for the kids. She can scoop these things into three red bags, and we will go meet her Wednesday at the train station.”

You can hear these words recited 1,300 times at the online speech accent archive at George Mason University in Fairfax, Virginia – and every one is different.

Inspired by Behat

Pride comes before a fall – A person who is extremely proud of his or her abilities will often suffer a setback or failure, because he or she tends to be overconfident and to make errors of judgment.  Latching onto Agile as a weak guide can give people a false sense of security.