why every product team should practice

[BEHAVIOUR-DRIVEN DEVELOPMENT]

It is important for everyone in a product or service team to understand how practicing behaviour-driven development will grow your output 10x

Disclaimer: no fancy graphs 📈

what is behaviour-driven development?

Since BDD is a subset of test-driven development, let's start there.
[BEHAVIOUR-DRIVEN DEVELOPMENT]

what is test-driven development?

TDD is the practice of writing test code before the implementation code for a new feature or functionality.
[BEHAVIOUR-DRIVEN DEVELOPMENT]

what's the difference?

It is a set of best practices for performing TDD within a team.

It carries the same principles and desired outcomes but the primary differentiation comes from focusing on behaviours rather than implementation when writing test cases.
[BEHAVIOUR-DRIVEN DEVELOPMENT]

Example

Let's consider the following new feature request from our product owner:
Description:
As a user, I want to be able to input two numbers in a calculator to see their sum.
Scenario 1:
I type 10 and 2 into the calculator input fields.
I press the `add` button.
I see the result of 12 appear on the screen.
[BEHAVIOUR-DRIVEN DEVELOPMENT]

TDD

BDD

suite('calculator', function() {
  test('add', function() {
    Calculator calculator = new Calculator();
    assert.equal(12, calculator.add(10, 2));
  });
});
describe('when using the calculator', function() {
    describe('and adding two numbers', function() {
        it('should give the user the sum of the two numbers', function() {
            Calculator calculator = new Calculator();
            int expectedSum = calculator.add(10, 2);
            assert.equal(12, expectedSum);
        });
    });
});
public class Calculator {

    ...

    public int add(int a, int b) {
        return a + b;
    }
}

Why practice BEHAVIOUR-DRIVEN DEVELOPMENT?

[BEHAVIOUR-DRIVEN DEVELOPMENT]

It is not complex, wasteful or backwards.

In fact, it is the complete opposite.

high confidence

  • 😎 Push changes that you know will not break anything in your code base
  • 🤝 Push changes that won't break API contracts with paying partners
  • 🐞 Reduce possibility for bugs: eliminate wasted time, maintain uninterrupted daily delivery cadence
[BEHAVIOUR-DRIVEN DEVELOPMENT]

code becomes human

  • 📚 Heightened understanding of the task at hand is paramount to reducing ambiguity, therefor reducing waste

  • 🚮 Significantly replace need for technical documentation since the tests explain the codebase from a human perspective
  • 👨‍👩‍👧‍👦 Increase engineers commercial understanding of and empathy for the task at hand, improving implementation code quality
[BEHAVIOUR-DRIVEN DEVELOPMENT]

optimise your people

  • 👫 Shared knowledge !== shared understanding; Onboard new team members far quicker

  • ⛑ DevOps, full-stack and support all become far easier to reason with due to the natural language most of your codebase is written in
[BEHAVIOUR-DRIVEN DEVELOPMENT]

Other related testing stuff

BDD by itself is great, but it gets even better with other related practices.
[BEHAVIOUR-DRIVEN DEVELOPMENT]

100% Test coverage

  • 💰 Good for business; increased reliability, satisfaction & speed to market

  • ⏱ Corrects perception of scope vs time. Time spent writing tests now to get that high test coverage will save you time, therefore money, fixing issues in the long run, fact
[BEHAVIOUR-DRIVEN DEVELOPMENT]

all types of testing

  • △ Unit tests (easy, solid, do it)
  • ⟁ 100% customer journey's via e2e (cumbersome, brittle, vital)
  • ⧋ 100% integration tests with third parties, decoupled system components etc. (hard, fiddly, integral)
[BEHAVIOUR-DRIVEN DEVELOPMENT]
The A-Model Pyramid, Compas Pascal

Continuous Integration,

continuous delivery

Nothing is of value until a customer is using it, so getting things in front of customers faster in order to start learning is the smartest thing we can do.


BDD adds extra robustness to a CI/CD pipeline.

 

The combination of solid tests and coverage along with automated testing gives you plenty of confidence on getting new features into production as quick as possible. 

[BEHAVIOUR-DRIVEN DEVELOPMENT]

What about the rest of the team?

  • 🧬 UI/UX designers need to create simplistic design shifts for individual stories that minimalise potential engineering faults
  • 🤹‍♀️ Product owners need to write stories that contain scenarios which allow engineers to move fast
  • 🔎 Data engineers, scientists or analysts need to provide solid measurable outcomes for success for user stories.
  • 🏈 Scrum masters need to ensure highly regular planning meetings occur and that engineers vote & discuss as a team and concrete outcomes.
[BEHAVIOUR-DRIVEN DEVELOPMENT]

red > green > refactor 

Simple rule to follow:


1. red:
   write the test cases first
   tests will fail ❌
2. green:
   implement the code
   tests will pass ✅
3. refactor:
   improve/refine the code
   tests should still pass ✅
[BEHAVIOUR-DRIVEN DEVELOPMENT]

Questions?

@mjrowles

Why every product team should practice behaviour-driven development

By Matt Rowles

Made with Slides.com

Why every product team should practice behaviour-driven development

An insight into the importance and relevance of Behaviour-driven development for all members within a product team.

  • 130

More from Matt Rowles