Back

From TDD to BDD

Image Slider

May 8, 2019

By Benoît Faurie – TheExpert Digital Factory at Squad

So we all more or less have the basic values ofAgilein mind, right? Okay, a quick reminder just in case?

The four values proposed by the agile manifesto are...

  • Individuals and their interactions rather than processes and tools
  • Operational software rather than exhaustive documentation
  • Collaboration with customers rather than contractual negotiation
  • Adapting to change rather than following a plan

… and broken down into 12 principles, which are… no, we're getting sidetracked here.

And what about TDD/BDD in all this?

First, TDD

Test-driven development (or development driven by tests for bilinguals) is a software development method that involves writing each test before writing the source code for a piece of software, in an iterative manner. TDD was initially called Test First Design, but patience and time are more powerful than force or rage (that's for you, La Fontaine), and the basic concept evolved and became TDD. It embodies the following three values:

  1. You must write a test that fails before you can write the corresponding production code.
  2. You must write only one assertion at a time, which causes the test to fail or fails to compile.
  3. You must write the minimum amount of production code necessary to satisfy the test assertion that is currently failing.

There you go, it was a bit of a struggle, but we're getting there little by little. So, to sum up, TDD is... ? A development method that allows you to develop better-designed, better-tested (indeed) and more reliable software. In short, we increase quality and meet Agile targets. Cool! Oh, this approach is called ATDD (Acceptance Test Driven Development).

The BDD

Behavior Driven Development is also a method used by Gilles, which encourages collaboration between technical and non-technical stakeholders. And at this point, any developer reading this is thinking, "Yeah, it's already hard enough to make non-technical people understand that I don't just do if/else statements, but if they start getting involved too, how am I supposed to get any work done? " That's where it gets (almost) magical. In fact, BDD emphasizes natural language and interactions in the software development process.

To summarize: the analyst/project manager/your boss writes the objective and benefit of the code in (almost) natural language. These are essentially specifications, and are generally similar to "user stories."

One solution: Cucumbers are nice, pickles are nice too.

What???!!

Yes, because I mainly work withLAMP/MEAN technologies (okay, here's a link to Wikipedia, otherwise this is going to take even longer), so I use Cucumber for my TDD development. The advantage of this tool is that it works for both JavaScript and PHP projects.

There you go, Gherkin is used for databases and corresponds to the syntax recognized by Cucumber for writing your boss's "specification."

Here is an example, and for those who are curious, I invite you to take a look at the documentation: https://docs.cucumber.io/gherkin/reference/#feature