Frontier Software

Robert Laing's programing notes

Behaviour Driven Design

By Robert Laing

FIRST

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

Red-Green-Refactor

  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.
describe
Groups examples hierarchically according to the set of behaviours they test.
it
Tests a single behaviour of a method.

http://xunitpatterns.com/Test%20Double.html

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

Definitions from Mocks Aren’t Stubs:

Dummy
objects are passed around but never actually used. Usually they are just used to fill parameter lists.
Fake
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).
Stubs
provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test.
Spies
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.
Mocks
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

Mock

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.

Double

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');
  });

Expectation

Seam

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

Stub

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

Last updated on 2 Jan 2021
Published on 2 Jan 2021

Content Footer