Testing: TDD, Mocha, and Chai

Learning Goals:

• Review the what and why of test driven development
• Examine the structure of a test and the testing lifecycle
• Practice writing tests

Vocab

• TDD Test Driven Development / Design
• Assertion An expression containing some testable logic
• Assertion Library A package of assertion functionality. Usually distinct from a Testing Framework
• Testing Framework A library that determines how tests are organized and executed
• Red Green Refactor The process of writing a test first (which will fail), then writing the implementation code to make it pass, then refactoring the tests and/or implementation with confidence
• Test Phases A test that is organized into the phases - Setup, Execution, Assertion, Teardown*

What Makes Testing Hard?

• At first, not knowing what to test
• So many libraries and frameworks to choose from, differing syntax in documentation
• Difficult to see the benefit until you’ve been saved by a failing test

What Should Be Tested?

When talking about what should be tested, we say that we want to test the outcome or result of a particular piece of code execution. This is an important distinction and can help clarify one of the key pieces of what makes testing hard.

For example, let’s say we have a quiz application that checks a user’s answers and adds/removes points from their score:

function createQuestion(questionText, correctAnswer) {
  let question = {
    questionText: questionText,
    correctAnswer: correctAnswer
  }
  return question
}

function checkAnswer(question, playerAnswer, score) {
  if (playerAnswer === question.correctAnswer) {
    score++
  } else {
    score--
  }
  return score
}

describe('checkAnswer', () => {
  it('should return incremented score when answer is correct', () => {

  });

  it('should return decremented score when answer is incorrect', () => {

  });
});

function reverseWord(word) {
  let letters = word.split('');
  letters.reverse();
  return letters.join('');
}

reverseWord('turing'); // gnirut

Reviewing Mocha vs. Chai

describe('checkAnswer', function() {
  it('should return incremented score when answer is correct', function() {

  });
});

  expect(result).to.equal(3);

Structure of a Test

Good tests have Four Phases:

1. Setup - Setup the conditions required to execute the action on your SUT
2. Execution - Execute some action on your SUT
3. Assertion - Assert that the action you did had the results you expect
4. Tear Down - Clean up any resources you used in your test (this is done automatically the majority of the time)

(Most tests you write will not need the Tear Down phase, but it’s good to know that step is there sometimes)

All of these phases deal with the Subject Under Test (SUT, or just subject).

Look at the following code example and make note of what we need to test:

let player = {
  name: 'Trisha',
  winningWords: []
}

function checkForWin(playerWord, correctWord, player) {
  if(playerWord === correctWord) {
    player.winningWords.push(playerWord)
    return 'Correct!'
  } else {
    return 'Incorrect, try again!'
  }
}

describe('checkForWin function', () => {
  it('should add word to player\'s winningWords when answer is correct', () => {

  });

  it('should not update player\'s winningWords when answer is incorrect', () => {

  });

  it('should return Correct! when answer is correct', () => {

  });

  it('should return Incorrect, try again! when answer is incorrect', () => {

  });
});

Now that we’ve determined what we need to test, read the comments that talk about each line of our tests

// Before anything can happen, we need a describe block to group related tests together
// In this case, the tests within our describe block are all related to the 'checkForWin' function 
describe('checkForWin function', function() {

  // Next, an 'it block' contains the context of each specific test
  it('should add word to player\'s winningWords when answer is correct', () => {

    // 1. "Setup"
    // Create the mock data we need to use in this test
        // Create a mock player
        // Create variable to hold the correctWord we'll use for this test
    var player = {
        name: 'Nick',
        winningWords: []
    };
    var correctWord = 'adore';

    // 2. "Execution"
    // Run appropriate functions that execute the behavior indicated by our test title
    // Pass in the arguments needed to test the specific path/scenario we're trying to test
    checkForWin('adore', correctWord, player);

    // 3. "Assertion"
    // Make assertion to verify that we end up with what we expect after executing the function
    expect(player.winningWords).to.deep.equal(['adore']);
  });

//Lets breakdown a sad path!
  // 'it block' contains the context of each specific test
  it('should not update player\'s winningWords when answer is incorrect', () => {

    // 1. "Setup"
    // Create the mock data we need to use in this test
        // Create a mock player
        // Create variable to hold the correctWord we'll use for this test
    var player = {
        name: 'Ben',
        winningWords: []
    };
    var correctWord = 'adore';

    // 2. "Execution"
    // Run appropriate functions that execute the behavior indicated by our test title
    // Pass in the arguments needed to test the specific path/scenario we're trying to test
        //This time we will pass an incorrect guess for the first arg in order to simulate and test the sad path
    checkForWin('spend', correctWord, player);

    // 3. "Assertion"
    // Make an assertion to verify that after executing certain functions, we end up with what we expect
    expect(player.winningWords).to.deep.equal([]);
  });
});

Testing Practice: Setup, Mocha, and Chai

To practice, let’s kick off a small project to demonstrate how you would utilize Mocha and Chai to write a couple tests.

git clone https://github.com/turingschool-examples/our-first-tests
cd our-first-tests
npm install

// test/box-test.js  

const chai = require('chai');
const expect = chai.expect;

describe('box functions', function() {
  it('should return true', function() {
    expect(true).to.equal(true);
  });
});

  ✓ should return true

1 passing (10ms)  

Testing Practice: Iteration 1

Obviously this test isn’t doing anything helpful, but we know our files are wired up. Let’s add some more interesting tests.

Work through the following iterations using TDD - meaning you will write the test first, then write the implementation code to pass each test.

Let’s pretend we just received a spec, and the first iteration looks something like this:

// test/box-test.js

const chai = require('chai');
const expect = chai.expect;

const {createBox, calculateArea} = require('../box');

describe('box', function() {
  it('should return true', function() {
    expect(true).to.equal(true);
  });

  it('should have a default height and a width', function() {
    var box = createBox()

    expect(box.height).to.equal(100);
    expect(box.width).to.equal(100);
  });

  it('should be able to take a height and a width as arguments', function() {
    var box = createBox(50, 40);

    expect(box.height).to.equal(50);
    expect(box.width).to.equal(40);
  });

  it('should calculate its area', function() {
    var box = createBox(30, 30);

    var area = calculateArea(box)

    expect(area).to.equal(900);
  })
});

// box.js  
function createBox(height, width) {
  var box = {
    height: height || 100,
    width: width || 100
  }
  return box
}

function calculateArea(box) {
  return box.height * box.width;;  
}

module.exports = { createBox, calculateArea };

Testing Practice: Iteration 2

Let’s continue to practice adding more iterations following the TDD process from before. Implement iteration 2 for our box per the spec outlined below.

Testing Practice: Iteration 3

Implement iteration 3 for our box per the spec outlined below;

Further Reading

• Hooks