bdd

We need to talk about testing

Or how programmers and testers can work together for a happy and fulfilling life.

Why don’t we just automate all the testing? Is test coverage a useful metric? What does it mean to “shift testing left”? When and where should we be testing? How much is enough testing?

The mystery of the missing date

My friend Gojko Adzic has been running a series of BDD quizzes illustrating different ways to approach some interesting BDD situations. I noticed on Twitter that Seb Rose, another BDDer (Cucumberer?), had gently taken issue with one of Gokjo’s solutions so I thought I’d take a look at them both. Before reading on I recommend reading Gojko’s solution and Seb’s response for context.

BDD by example

tl;dr: Send us your examples of real world BDD. Read on to find out why.

The panel

“What is BDD?”

“How can I tell if I’m ‘doing BDD right’? Or wrong? Is there even such a thing?”

“Where should I start?”

“Is this or that practise considered part of BDD?”

“What are the mandatory ”core“ practises of BDD?”

These and similar questions were the topic of the closing panel at the recent CukeUp conference in London.

Whose domain is it anyway?

The brittleness of tests or specs is a recurring topic in BDD (or acceptance test-driven development, specification-by-example, or whatever you choose to call the thing where you write acceptance criteria, automate them and then make the application match). This is a tricky area, and there are probably as many styles of defining and grouping acceptance criteria as there are teams automating them.

The aspect I want to focus on in this article is domain language, because there’s a failure mode I encounter surprisingly often, which seems to have a common root cause.

New translations

I currently have a backlog of about 15 blog articles I am failing to finish. The most embarrassingly laggy one dates from around the end of 2007. Now I know I’m a slacker.

However, others have been far more industrious than me.