BDD

An Ubiquitous Domain language throughout testing

One of the biggest challenges as engineers is to write working software and also keep an extensive documentation. Most engineers hate writing documentation, and after they published documentation on a wiki it will die a lonely death. We want to strive for writing a Living Documentation in an Ubiquitous Language. Practices like Domain Driven Design (DDD) and Behaviour Driven Development (BDD) can help you achieve this. Especially when we start writing code, it is really important for the quality of our software to start with tests describing what your application does. We want to write software with empathy in mind, software that is understandable for peers. While software developers are beginning to use the language of the domain (business language) more in their application code, most tests still contain a lot of technical language.

(more…)

By Kenny Baas-Schwegler, ago

Be carefull using UI Designs as a visual during your BDD refinements

 

The practise of Behaviour Driven Development (BDD), and using tooling to support this like cucumber, has inspired many posts and talks. The recurring questions are predominantly about how teams and people pull these tools out of its collaboration context, and bring it into the test automation context. Cucumber’s post might perhaps be one of the best on this topic,

Last year I started giving talks about BDD based on my own experiences. One pitfall that always seems to pop up, at least in the Netherlands, is about imperative versus declarative (or implementation vs intention).

(more…)

By Kenny Baas-Schwegler, ago