Why do we Unit Test (and what’s the purpose of Code Coverage)?

What is Unit Testing? Unit Testing is the approach of testing the smallest parts of our code in isolation from other code. In Java these are methods in our classes. In Javascript these are our functions.

There are many unit testing frameworks that help us with our unit tests. In Java we have JUnit and TestNG, both have been around for a long time. The key part they help us with is making ‘assertions’ about the results of our code under test, to check the results and confirm when we call our code, it returns the expected results.

Why do we Unit Test? As developers we want to know our code works, that it does what it is supposed to do. We use unit tests to give us confidence about our code, so we know it works.

We can use unit tests to help with code changes or refactoring efforts to improve existing code. If existing tests are available, you can use them to check that they are showing you were the issue is that you need to fix (assuming there’s a test for that part of the code), or check that the existing code is working before your refactoring changes.

A typical flow for using unit tests to help with a defect fix looks like:

Run test, confirm test fails. Make code fix, confirm test passes. If the unit test for the related code doesn’t have an existing test for the code where the issue is, add a new test. Write a test for the expected result which should initially fail, rerun after the code fix and now the test should pass to confirm your fix is working.

Run other related tests in the same area to check there are no unexpected impacts to other existing code.

We can also use unit tests as part of a CI/CD pipeline – when our tests pass, the code is ready to include in a new build, and depending on your development process, ready for additional tests, integration testing, UAT testing and promotion into production.

Many industry studies have shown that it’s always cheaper to find and fix defects in our code earlier than later. The time invested to develop unit tests saves us in the long run if we can find issues earlier and avoid finding issues later, e.g. in production.

Any number of unit tests does not prove that our code is 100% correct however, neither does it prove the absence of bugs. If our unit tests are effective though, they can give us confidence that our code is working as expected for a range of tested inputs.

What is an effective test?

An effective unit test must have assertions to check and confirm the code when executed with given parameters returns the expected results. In JUnit, the framework provides a number of assert statements, like assertTrue(), assertEquals() that you use to confirm the expected results.

A unit test without assertions that only calls the code under test is not an effective test. Without assertions, the test is useless if you’re not checking the expected results.

Similarly for assertNotNull(). If the only thing your test does is check that there’s a non-null result, this doesn’t confirm that the code is returning the expected result, it only confirms a value is returned. This is not particularly useful when we expect a unit test to confirm that the code is returning the expected results (i.e. it is working).

For any given method that takes parameters, you should have a range of test methods to confirm the expected results for that range of input values. You should obviously test with expected/valid input values, but you should also test with a few unexpected/invalid values: high values, low values, empty, short and long strings. In all cases you should assert and confirm that the method returns the expected results.

How does Code Coverage relate to Unit Testing?

Code Coverage tells you how much of your code was execute by your tests. As a tool it is useful during the development of your unit tests, because it helps highlight where your tests may have missed paths through the code. For example, if the code you are testing has an if..then..else condition and your test calls the code with parameters that causes the if condition block to be tested but not the else block, Code Coverage helps highlight untested code.

The problem with Code Coverage though, is that by itself, Code Coverage is not an indication of effective tests or even working tests. If you have a test without an assertion that calls a method with a single block of lines of code and each of those lines executes, Code Coverage will report 100% coverage on this block. Without an assertion, this test doesn’t test that the code works, and therefore is worthless. It does have 100% Code Coverage though. This is why relying on Code Coverage alone is not useful, or sensible, because it doesn’t tell you how effective your tests are. It only tells you how much of the code was executed. Code that is executed by a test but is not confirmed if it is returning expected results or not with assertions, is just executed code, not working code.

Remember your assertions.

Use Code Coverage as a tool to help you find untested code, not as an ultimate goal: writing tests to achieve Code Coverage is not useful. Developing effective tests is your goal.

More React unit testing with Jest and Enzyme

I’ve been writing some additional tests to get a better idea of how to use Jest and Enzyme for testing my React components (see my first attempts here).

I have a simple Flux app that had a LabelComponent and a ButtonComponent. The full source is here. I want to test the render output is what I expect. The render method on my LabelComponent is pretty simple:

render() {
    return (
        <div className="label">
            Text: { this.state.labelValue.value }
        </div>
    );
}

This component has state which comes from a Store, so this seems a little more interesting to test.

Using Enzyme you can either fully render a component to a virtual DOM using mount() and then check the results, or you can shallow() render which only renders that component and not any additional child dependencies (this is probably more useful for unit tests).

Using mount(), you can check for expected rendered output in the resulting DOM using .contains() – without doing anything to initialize the Store, this is my first step:

import React from 'react';
import {shallow, mount} from 'enzyme';
import LabelComponent from '../components/LabelComponent';
it('renders with text value', () => {

    const result = mount(<LabelComponent/>);
    expect(result.contains(<div className="label">Text: </div>));
});

This is good so far, but I’m really more interested in how the component renders when the Store contains values to be rendered. I’m not sure if I’ve found the right way to do this, but looking for info on how to mock out other parts of my app, like the Store, took me down a rabbit hole. The Jest docs for mocking are not particularly useful. In the api reference there’s something that looks like it allows you to setup a mock return from a function, but it doesn’t have enough info to tell you exactly how to use it.

It seems the Jest api has changed enough over time that it’s hard to find any articles that are current, and show you how the current api should be used. This SO post has a question that’s pretty close to what I was trying to do. There’s two answers that combined together got me to a working solution.

This approach didn’t work for me:

const getData = jest.fn().mockImplementation(() => {
    return {
        getData: jest.fn().mockReturnValue({'labelValue' : { 'value' : 'test'} } )
    }
});

… but, this approach did exactly what I needed:

jest.mock('../stores/LabelStore');
import LabelStore from '../stores/LabelStore';
const getData = jest.fn().mockImplementation(function() {
    return {'labelValue' : { 'value' : 'testvalue'} }
    }
);
LabelStore.getData = getData.bind(LabelStore);

As far as I work out, this is mocking my getData() function to return the mocked data I want for testing, and then binding it to a mocked LabelStore.

I’m not sure if this is the best approach for mocking with Jest, but this is doing exactly what I need. If I learn more about this approach I’ll come back and provide an update later.

Unit testing React components with Jest

Jest is a unit test framework for testing React apps. The Getting Started guide is pretty much all you need to get started. If you’ve created your project using create-react-app then you’re already setup, just run ‘npm test’ and a runner will test up that repeatedly runs your tests as you make code or test changes.

create-react-app also creates a sample test for the sample App.js component. This is a good starting point to follow for other tests:

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';

it('renders without crashing', () => {
  const div = document.createElement('div');
  ReactDOM.render(<App/>, div);
});

To test the results of rendering a component, the enzyme library allows you to easily capture the output from a render, and then query the results. For example:

import React from 'react';
import ReactDOM from 'react-dom';
import {shallow, mount} from 'enzyme';
import Calculator from '../Components/CalculatorComponent';
it('renders with result 3', () => {
    const result = mount(<Calculator value1="1" value2="2" />);
    result.find('button').simulate('click');
    const buttonResult = result.find("#result").first();
    expect(buttonResult.text()).toEqual("3");
});

The CalculatorComponent I’m testing here is the one from my previous React post.

WebStorm: adding library support for Jasmine

WebStorm provides support to download libraries to provide code complete for a huge number of popular libraries.

I tried to add a Library for Jasmine manually, but really wasn’t sure where to point to, I tried pointing to here, but this didn’t seem to work for me:

/usr/local/lib/node_modules/karma-jasmine

If you press the Download button on the right, you can search for a known library and install it like this:

I think part of what I was looking for was jasmine and karma-jasmine, but installing from the Download option got these setup for me, and now I’ve got the code complete in my Jasmine tests that I was looking for.