Frontier Software

Robert Laing's programing notes

Behaviour Driven Design

By Robert Laing


  • F ast
  • I ndependent
  • R epeatable
  • S elf-checking
  • T imely


  1. Before you write any new code, write a test for one aspect of the behaviour it should have. Since the code being tested doesn’t exist yet, writing the test forces you to think about how you wish the code would behave and interact with its collaborators if it did exist. We call this “exercising the code you wish you had”.
  2. Red step: Run the test, and verify that it fails because you haven’t implemented the code necessary to make it pass.
  3. Green step: Write the simplest possible code that causes this test to pass without breaking any existing tests.
  4. Refactor step: Look for opportunities to refactor either your code or your tests — changing the code’s structure to eliminate redundancy, repetition, or ugliness that may have arisen as a result of adding the new code. The tests ensure that your refactoring doesn’t introduce bugs.
  5. Repeat until all behaviours necessary to pass a scenario step are complete.
Groups examples hierarchically according to the set of behaviours they test.
Tests a single behaviour of a method.

xUnit tests follow a typical four phase sequence: setup, exercise, verify, teardown.

Definitions from Mocks Aren’t Stubs:

objects are passed around but never actually used. Usually they are just used to fill parameter lists.
objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test.
are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Subject Code

Code being tested


Mocks isolate the subject code from other code which might have bugs of its own.

Mocks are like puppets whose behaviour we completely control, allowing us to isolate unit tests from their collaborator classes and keep tests I ndepenent.

spyOn(window, "server_call").and.returnValue({...});

Use mock when you’re going to ask the fake object to do things.


Doubles are simply stand-ins, eg to skip things to help keep tests F ast.

  beforeAll(function() {
    spyOn(window, 'requestAnimationFrame');
    spyOn(window, 'addEventListener');
    spyOn(canvas, 'addEventListener');



A place where you can alter behaviour in your program without editing in that place.


Stubs are placeholders in the subject code rather than test code.

Last updated on 2 Jan 2021
Published on 2 Jan 2021

Content Footer