Tag Archives: bdd

Behavioural Driven Development

What Software Development Can Learn from Double-Entry Bookkeeping

Posted on by
Reply

Double-entry bookkeeping revolutionised business by introducing a self-checking system of financial integrity. In the world of software, Behaviour-Driven Development (BDD) does something strikingly similar — pairing each feature with a clear, testable description of how it should behave. Double-entry bookkeeping and automated software testing might seem worlds apart – one emerged in Renaissance-era accounting and the other in modern software development. Yet conceptually, they serve a similar purpose: both introduce systems of checks and balances to ensure integrity and accuracy in their respective domains. In accounting, double-entry bookkeeping requires every transaction to be recorded in two accounts (debits and credits) that must balance, creating an internal self-checking mechanism. In software, automated tests act as a parallel record of expected behaviour, continuously verifying that the code produces the intended outcomes. This post explores how a 500-year-old accounting innovation revolutionised financial record-keeping and how its spirit lives on in the way we write and test software today.

Continue reading →

Test driven architecture – use your tests to inform architecture

Posted on by

As test-loving development teams, we are all painfully aware of the complexity of getting an application into the zen state of development – quick, test-driven red/green feedback for developers, software designs that are functionally on-the-money from a test-led, “outside-in” approach (from BDD), and a nigh on seamless continuous delivery process as a result. Very few teams achieve this, and those that do are frequently gifted a green-field project in which to engender them.

As test-savvy teams, when tests start to hamper the release process, we often assume our approach to testing needs an overhaul, but that might not be the case. Here we look at the role of architecture in test-driven applications, and examine whether we should listen to our tests to examine our macro design.
Continue reading →

Who is Specification by Example for? Everybody!

Posted on by

I was talking to Pedro Santos on the train the other day. Pedro is my technical lead, an expert in his field and a keen advocate of automated testing and software craftsmanship in general. We were talking about Gherkin and Pedro was saying he doesn’t see Gherkin tests adding value because it doesn’t help him as a developer. Of course I disagree. The way I look at it is the Gherkin tests are not for the developers. The Gherkin tests are for the organisation – they are for everybody.
Continue reading →

PMs Need a Technical Ally When Introducing Automated Testing

Posted on by

I need a technical ally when introducing Specification by Example and BDD. Actually I need a technical ally when introducing automated testing of any kind. Somebody to coach / mentor / encourage / explain / enthuse about the technology and how it helps.
Continue reading →

Specification by Example helps even with no Automation

Posted on by

I’m keen on Specification by Example particularly with a tool like Cucumber to automate tests. However this style of specification is also useful without the automation. I introduced my current team to Specification by Example and, with some help from me, the customer is now using the same disciplines to define requirements to hand to a 3rd party development shop. The experiment has been very successful.
Continue reading →

Three Amigos Meeting – Agree the tests before development starts

Posted on by

“Three Amigos” is what Matt Wynne calls the meeting to discuss the Gherkin scenarios before development starts. The Three Amigos involves the business, development and testing voices. However who turns up, where they meet, what they produce in the meeting, the homework to complete after the meeting, and who does that homework can all vary depending on the particular team.
Continue reading →