Test Driven Development (TDD) is one of the best ways to make sure your code is high quality and works like it's supposed to work. It can also help you create reliable builds during continuous deployments.

In this post, we will learn how to create a Svelte application using TDD methods.

What We're Building

We are going to build a vertical tabs component where we can switch between three tabs. We are going to build this component by writing test cases first and developing the component functionality after that to make the tests more effective.

Final implementation

Prerequisite

I will explain all the steps needed to create an app and you can follow along with the code. It's great if you have basic programming knowledge and fundamental knowledge of HTML and CSS for this tutorial.

Also, you'll need to have Node.js installed. You can see how to do that here if you don't have it already.

What is Test-Driven Development?

The basic idea of test-driven development, or TDD, is to write the test before you implement the actual functionality. This helps you clearly figure out what you're developing and how it works.

You first watch the test fail, and then you write the code to make it pass. This ensures that there are no false positive tests in your code.

TDD is a methodology you can apply to any programming language. It is more prevalent when developing backend applications that contain business logic that you can easily test.

The good news is, you can apply similar techniques to test your front-end applications as well.

Three stages of TDD

The three stages of TDD are:

1. Red stage – Write the test and watch it fail
2. Green stage – Write the minimum code required to make the test pass
3. Refactor – Cleanup and refactor the code to make it more robust

Three stages of TDD

What is Vitest?

Vitest is an up-and-coming testing framework which has similar functionality to Jest.

Since we are using Vite as our build tool for Svelte in this tutorial, Vitest has very good integration with Vite and offers a similar testing environment without needing extra configuration.

How to Create a Svelte Application

We are going to create a Svelte application using Vite as the build tool. You can do that with this command:

npm create vite@latest

This will create a new project, and you can follow the steps below to create and setup the project:

1. Enter the name of the project. This will also create a new folder with the project name. In this example, I will add the project name as svelte-tdd-vitest.
2. You can select the framework in the next step. Let's choose svelte as the framework.
3. Then you can enter the variant of the framework. We can choose the TypeScript variant for this article. If you are not comfortable with TypeScript, you can also choose JavaScript in this option.

Initialise Svelte project with Vite

You can then follow the helpful steps provided in the terminal to install the dependencies and start the application. Run the following command:

cd svelte-tdd-vitest
npm install
npm run dev

npm install will install the dependencies of the project.

npm run dev will start the development server. You should see the app running in the port specified in the terminal.

Vite Server started using npm run dev

Congrats, you can now see the starter app running in your browser. You can open the project in your favourite Code Editor and start working.

How to Set Up Vitest

You can add Vitest to the project right now as a dev dependency. This means that Vitest will not be packaged into the production build of the application since you will be running the test in your local environment.

npm install -D vitest

Vitest can read the config of Vite inside the vite.config.js file and prepare the test environment similar to the build environment. This makes the test more reliable. So you can reuse the Vite config file and add more options for the configuration of Vitest.

You can also override the config for the Vitest by creating a new file called vitest.config.js in the project root. So now, create a new file called vitest.config.js:

import { defineConfig } from 'vitest/config'
import { svelte } from '@sveltejs/vite-plugin-svelte'

export default defineConfig({
  plugins: [
    svelte({ hot: !process.env.VITEST }),
  ],
  test: {
    environment: 'jsdom',
  }
})

There are a couple of configs we are adding to the file

1. We are disabling Svelte's hot module reload when tests are running.
2. We are defining the environment for running the test as jsdom. It helps in mocking the DOM API and running the tests in a reliable method.

In order to use the jsdom you need to add it as an Dev Dependency as well. So let's install that package using the terminal.

npm install -D jsdom

After installation, let's add a couple of scripts to the package.json file to start the Vitest test from the npm command line:

"scripts": {
    ...
    "test": "vitest",
        "coverage": "vitest run --coverage"
}

How to Create the First Test

You now have all the setup needed to write your first test. Create a new file called sample.spec.ts inside the lib directory.

import {describe, test, expect } from 'vitest';

describe("Example File", () => {
    test("Sample test", () => {
        expect(1 + 3).equal(4);
    });
});

Let's break down the different functions used to create this test file:

1. describe – you use this to group similar test together and benchmark tests when generating your reports. It takes a name and a function that contains the group of tests.
2. test – Represents a single test. It can contain multiple expectations within it. It is created by passing a name of the test and the function to run the test.
3. expect – Represents the expression which you're testing.

There are multiple different ways to write your test based on what you are testing. You can have a look at the complete API for Vitest in the official API Reference.

Let's run the test using the following npm command:

npm run test

Running the test

How to Add the Global Test Config

You are going to be using the describe, test, and expect functions a lot in the test files and it might be verbose to import them in all the test files. So Vitest has a nice config where you can set these global imports and so you don't have to add them to each file.

So let's update the vitest.config.js file with this configuration:

export default defineConfig({
  ...
  test: {
    ...
    globals: true
  }
})

After adding this globals equals true line in your config, you can now remove the imports in your spec file.

If you are using TypeScript, your TypeScript compiler will complain in your spec file. You can solve that by adding the following line to your tsconfig.json file:

{
  "extends": "@tsconfig/svelte/tsconfig.json",
  "compilerOptions": {
    ...
    "types": ["vitest/globals"]
  },
}

Now your test can look like this. This is not a huge upgrade for this small file, but when you have lots of spec files, this config change is useful.

describe("Example File", () => {
    it("Sample test", () => {
        expect(1 + 3).equal(4);
    });
});

How to Create a Svelte Component

We will create a new svelte component called VerticalTabs.svelte. The requirements are to create a vertical tab component that can contain a few items and for the user to be able to select a particular tab to view its content in the right side.

The component will be divided into two parts. The left side displays all the tabs. The right side displays the content based on the tab.

Let's create the basic HTML and CSS styles needed for the component. We will add the functionality to switch tabs after writing the tests.

<div class="vertical-tab-container">
    <ul class="vertical-tab">
        <li>First Tab</li>
        <li>Second Tab</li>
        <li>Third Tab</li>
    </ul>

    <div class="vertical-tab-content">
        <h2>First Tab Heading</h2>
        <p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Autem aut deserunt veniam tempora deleniti quos reprehenderit natus. Animi, obcaecati dolorum, culpa, maiores maxime ullam soluta unde rerum nihil temporibus quibusdam!</p>
    </div>
</div>

<style>
    .vertical-tab-container {
        display: flex;
        flex-direction: row;
        align-items: center;
        border: 1px solid gray;
        border-radius: 1rem;
    }

    .vertical-tab {
        margin: 0px;
        padding: 3rem;
        list-style: none;
        border-right: 1px solid gray
    }

    .vertical-tab li {
        margin: 2rem 0;
    }

    .vertical-tab-content {
        flex:1
    }
</style>

In this code, you are adding simple elements like an unordered list to display the list of tabs. You are styling it in the <style> tag which will be locally scoped CSS for this component.

Then, you are adding <h2> tag to display the tab heading and a paragraph tag <p> to show more dummy text for the tab. You're using flex to show the two items side by side and the property of flex: 1 on the content will make that container take all the remaining available space to expand.

The component should look like the below image:

Vertical Tab initial

How to Mount the Svelte Component in Test

Now you need to create the first test for the component by mounting the svelte component and then checking to see if you can find the "First Tab" text in the component.

So create a new spec file called VerticalTabs.spec.ts:

import VerticalTabs from "./VerticalTabs.svelte";

describe("VerticalTabs Component", () => {

    test("should render the component", () => {
        // Create a new container for the test
        const host = document.createElement('div');

        // Append the new container in the HTML body
        document.body.appendChild(host);

        // Create an instance of the vertical tab
        const instance = new VerticalTabs({ target: host });

        // Check if the instance has value
        expect(instance).toBeTruthy()

        // Test if we can find the "First Tab Heading"
        expect(host.innerHTML).toContain("First Tab Heading")

    });

})

In order to mount the Svelte component, you need to first create a div container and attach that div to the body of the HTML document. Then you need to attach your component to the div. You can then test the innerHTML of the main container to see if you have the required content.

Now this test should pass since you have the First Tab Heading content displayed in the component.

Going through this long process in all the steps might prove to be difficult. So let's add another package to make the job easier. The package is testing-library/svelte and it provides more features to make the assertions easy and less verbose.

How to Use the Svelte Testing Library

First, you'll need to install the library:

npm install -D @testing-library/svelte

Let's update the previous test to make it less verbose and let testing-library handle all the heavy lifting for us. You can use the render function to add the component to the testing page.

import VerticalTabs from "./VerticalTabs.svelte";
import { render, screen } from '@testing-library/svelte';

describe("VerticalTabs Component", () => {

    test("should render the component", () => {

        render(VerticalTabs);

        const firstTabNode = screen.getByText(/First Tab Heading/i)

        expect(firstTabNode).toBeTruthy()
    });

})

After the render function, add the component to the testing page. You can use the screen object imported from the library to query the nodes that are rendered.

There are multiple methods inside this object to make testing easy, and you will use one of the methods to get the text in the component.

getByText will return the instance of a given text. You are expecting the node to contain some value.

There are three main ways to retrieve the element in the testing library, and each serves a different purpose:

1. getByText – This will throw an error when the text is not found and the test will fail
2. queryByText – This will return null when the text is not found
3. findByText – This will also throw an error when the text is not found and you can use it when doing async tests where the element will take some time to appear/disappear

You can find a useful summary of these helper functions in the official docs page.

Summary screenshot from Official docs of testing library

You can find more details on this API in this official page.

How to Build the Tab Switching Feature

We will start adding the feature to switch tabs in the component and test the component by writing the test first.

Red stage

Let's write a test the switch to a different tab on click of the "Second Tab" list item.

Since we don't have this functionality implemented, we will fail this test first and that's okay. Once we fail the test, we should write the logic to make it pass in the next step.

So let's write a failing test:

test("should switch tabs", async () => {
        render(VerticalTabs);

        const secondTabElement = screen.getByText(/Second Tab/i);

        fireEvent.click(secondTabElement)

        await screen.findByText(/Second Tab Heading/i);
})

We are using the fireEvent from the testing library to simulate the click of the element. We can make the test async and await for the element since the text will change after the element is clicked.

You should have a failing test now:

Test failing unable to find the content

Green stage

Let's add the logic to change the tab in the Svelte component. We can do that easily by creating a selectedIndex variable and changing its value based on the selected tab.

<script lang="ts">
    let selectedIndex = 0;

    const changeSecondTab = () => {
        selectedIndex = 1;
    }
</script>

<div class="vertical-tab-container">
    <ul class="vertical-tab">
        <li>First Tab</li>
        <li on:click={() => changeSecondTab()}>Second Tab</li>
        <li>Third Tab</li>
    </ul>

    <div class="vertical-tab-content">
        {#if selectedIndex == 0}
            <h2>First Tab Heading</h2>
            <p>...</p>
        {:else if selectedIndex == 1}
            <h2>Second Tab Heading</h2>
            <p>...</p>
        {/if}
    </div>
</div>

Note: This is not the best implementation. It is only meant for showing that you can do minimal work to make the test pass. We will clean it up in the next stage

We have a method changeSecondTab that will change the selectedIndex value to 1 which will make the #if condition to change the tab. Even though it is not the best solution to handle all cases, we have a starting point.

Let's look at the test now. It should be working:

Refactor

Let's fix the implementation to make it more generic and have it work for all three tabs. We can also add an indicator to show which tab is currently selected.

<script lang="ts">
    let selectedIndex = 0;

    const changeTab = (index: number) => {
        selectedIndex = index;
    }
</script>

<div class="vertical-tab-container">
    <ul class="vertical-tab">
        <li class:selected={selectedIndex == 0} 
            on:click={() => changeTab(0)}>First Tab</li>

        <li class:selected={selectedIndex == 1} 
            on:click={() => changeTab(1)}>Second Tab</li>

        <li class:selected={selectedIndex == 2} 
            on:click={() => changeTab(2)}>Third Tab</li>
    </ul>

    <div class="vertical-tab-content">
        {#if selectedIndex == 0}
            <h2>First Tab Heading</h2>
            <p>...</p>
        {:else if selectedIndex == 1}
            <h2>Second Tab Heading</h2>
            <p>...</p>
        {:else}
            <h2>Third Tab Heading</h2>
            <p>...</p>
        {/if}
    </div>
</div>

<style>
    ...
    .selected {
        color: blue;
    }
</style>

We have created a method changeTab that will be called on the click of each element and then change the selectedIndex. This will cause the #if logic to change the tab based on its value.

We also have class:selected followed by an expression and when the expression becomes true, the selected class is added to the element. So we have added one more CSS class and we made the text colour blue to show the selected tab.

Finished vertical tabs component

Test after finishing refactor

We have now confirmed that the test is also passing after the refactor. You can continue this process to add more tests and features to your component.

How to Add Animation

Svelte makes it easy to add animation when content is changed. You can make use of the transition directive to add pre-built animation to your application.

So let's add a fly animation when the content changes. You can import the fly animation from svelte/transition and then add it to the element using transition:fly. This will add the default fly animation when the content flies out and new content flies in. Such a neat effect with just a single line of code!

import { fly } from 'svelte/transition';

<div class="vertical-tab-content" >
        {#if selectedIndex == 0}
            <div transition:fly>
                <h2>First Tab Heading</h2>
                <p>...</p>
            </div>
        {:else if selectedIndex == 1}
            <div transition:fly>
                <h2>Second Tab Heading</h2>
                <p>...</p>
            </div>
        {:else}
            <div transition:fly>
                <h2>Third Tab Heading</h2>
                <p>...</p>
            </div>
        {/if}
    </div>

Animation brings life to your application and helps it stand out. I am a big fan of the simple animation transition system in Svelte.

Conclusion

In this tutorial, you have learned how to create a new component using test-driven development methodology. Please share your feedback on this post and let me know your thoughts.

Thanks for reading! You can contact me on Twitter @sriram_thiagar. I regularly post articles on my blog eternaldev.com if you want to read more articles from me.

Hello everyone. I am Sriram, and I work as a Full Stack developer. I like to share my learning with others. I have been blogging for more than a year now on my website.

This tutorial will show you all you need to implement test-driven development in your JavaScript and React applications.

Table of Contents

1. What Is Test-Driven Development?
2. JavaScript Example of a Test-Driven Development Workflow
3. How to Use Jest as a Test Implementation Tool
4. Important Stuff to Know about Using ES6 Modules with Jest
5. What Are the Advantages of Test-Driven Development?
6. What is a Unit Test in Test-Driven Development?
7. What is an Integration Test in Test-Driven Development?
8. What is an End-to-End Test in Test-Driven Development?
9. What are Test Doubles in Test-Driven Development?
10. Quick Overview of Test-Driven Development So Far
11. How to Test React Components
12. Test Runner vs. React Component Testing Tool: What's the Difference?
13. Project: How React Testing Works
14. Overview

So, without any further ado, let's get started by discussing what test-driven development means.

What Is Test-Driven Development?

Test-driven development (TDD) is a coding practice where you write the result you want your program to produce before creating the program.

In other words, TDD requires you to pre-specify the output your intended program must produce to pass the test of functioning the way you envisioned.

So, in an effective test-driven development practice, you would first write tests that express the result you expect from your intended program.

Afterward, you would develop the program to pass the prewritten test.

For instance, suppose you wish to create an addition calculator. In such a case, the TDD approach will be like so:

Test-driven development workflow diagram

1. Write a test specifying the result you expect the calculator to produce to pass the test of being the program you had in mind.
2. Develop the calculator to pass the prewritten test.
3. Run the test to check whether the calculator passes or fails the test.
4. Refactor your test code (if necessary).
5. Refactor your program (if necessary).
6. Continue the cycle until the calculator matches your vision.

Let's now see a JavaScript example of a TDD workflow.

JavaScript Example of a Test-Driven Development Workflow

The steps below will use a simple JavaScript program to show you how to approach TDD.

1. Write your test

Write a test that specifies the result you expect your calculator program to produce:

function additionCalculatorTester() {
  if (additionCalculator(4, 6) === 10) {
    console.log("✔ Test Passed");
  } else {
    console.error("❌ Test Failed");
  }
}

2. Develop your program

Develop the calculator program to pass the prewritten test:

function additionCalculator(a, b) {
  return a + b;
}

3. Run the test

Run the test to check whether the calculator passes or fails the test:

additionCalculatorTester();

Try it on StackBlitz

4. Refactor the test

After you've confirmed that your program passed the prewritten test, it's time to check if there's any need to refactor it.

For instance, you could refactor additionCalculatorTester() to use a conditional operator like so:

function additionCalculatorTester() {
  additionCalculator(4, 6) === 10 
    ? console.log("✔ Test Passed") 
    : console.error("❌ Test Failed");
}

5. Refactor the program

Let's also refactor the program's code to use an arrow function.

const additionCalculator = (a, b) => a + b;

6. Run the test

Rerun the test to ensure your program still works as intended.

additionCalculatorTester();

Try it on StackBlitz

Notice that in the examples above, we implemented TDD without using any libraries.

But you can also use powerful test-running tools like Jasmine, Mocha, Tape, and Jest, to make your test implementation faster, simpler, and more fun.

Let's see how to use Jest, for example.

How to Use Jest as a Test Implementation Tool

Here are the steps you'll need to follow to get started using Jest as your test implementation tool:

Step 1: Get the right Node and NPM version

Make sure you have Node 10.16 (or greater) and NPM 5.6 (or greater) installed on your system.

You can get both by installing the latest LTS from the Node.js website.

If you prefer to use Yarn, ensure you have Yarn 0.25 (or greater).

Step 2: Create a project directory

Create a new folder for your project.

mkdir addition-calculator-jest-project

Step 3: Navigate to your project folder

Using the command line, navigate to your project directory.

cd path/to/addition-calculator-jest-project

Step 4: Create a package.json file

Initialize a package.json file for your project.

npm init -y

Or, if your package manager is Yarn, run:

yarn init -y

Step 5: Install Jest

Install Jest as a development dependency package like so:

npm install jest --save-dev

Alternatively, if your package manager is Yarn, run:

yarn add jest --dev

Step 6: Make Jest your project's test runner tool

Open your package.json file and add Jest to the test field.

{
  "scripts": {
    "test": "jest"
  }
}

Step 7: Create your project file

Create a file that you will use to develop your program.

touch additionCalculator.js

Step 8: Create your test file

Create a file that you will use to write your test cases.

touch additionCalculator.test.js

Note: Your test file's name must end with .test.js—so that Jest can recognize it as the file containing your test code.

Step 9: Write your test case

Open your test file and write some test code that specifies the result you expect your program to produce.

Here's an example:

// additionCalculator.test.js

const additionCalculator = require("./additionCalculator");

test("addition of 4 and 6 to equal 10", () => {
  expect(additionCalculator(4, 6)).toBe(10);
});

Here's what we did in the snippet above:

1. We imported the additionCalculator.js project file into the additionCalculator.test.js test file.
2. We wrote a test case specifying that we expect the additionCalculator() program to output 10 whenever users provide 4 and 6 as its argument.

Note:

• test() is one of Jest's global methods. It accepts three arguments:
  1. The name of the test ("addition of 4 and 6 to equal 10").
  2. A function containing the expectations you wish to test.
  3. An optional timeout argument.
• expect() is a Jest method that lets you test the output of your code.
• toBe() is a Jest matcher function that enables you to compare expect()'s argument to primitive values.

Suppose you run the test code now. The test would fail because you've not developed the program for which you created the test. So, let's do that now.

Step 10: Develop your program

Open your project file and develop a program to pass the prewritten test.

Here's an example:

// additionCalculator.js

function additionCalculator(a, b) {
  return a + b;
}

module.exports = additionCalculator;

The snippet above created an additionCalculator() program and exported it with the module.exports statement.

Step 11: Run the test

Run the prewritten test to check if your program passed or failed.

npm run test

Alternatively, you can use Yarn like so:

yarn test

Suppose your project contains multiple test files, and you wish to run a specific one. In such a case, specify the test file as follow:

npm run test additionCalculator.test.js

Alternatively, you can use Yarn like this:

yarn test additionCalculator.test.js

Once you've initiated the test, Jest will print a pass or fail message on your editor's console. The message will look similar to this:

$ jest
 PASS  ./additionCalculator.test.js
  √ addition of 4 and 6 to equal 10 (2 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        2.002 s
Ran all test suites.
Done in 7.80s.

If you prefer Jest to run your test automatically, add the --watchAll option to your package.json's test field.

Here's an example:

{
  "scripts": {
    "test": "jest --watchAll"
  }
}

After adding --watchAll, re-execute the npm run test (or yarn test) command to make Jest automatically begin rerunning your test whenever you save changes.

Note: You can quit the watch mode by pressing the Q key on your keyboard.

Step 12: Refactor the test code

So, now that you've confirmed that your program is working as intended, it's time to check if there's any need to refactor the test code.

For instance, suppose you realized that the additionalCalculator should allow users to add any number of digits. In that case, you can refactor your test code like so:

// additionCalculator.test.js

const additionCalculator = require("./additionCalculator");

describe("additionCalculator's test cases", () => {
  test("addition of 4 and 6 to equal 10", () => {
    expect(additionCalculator(4, 6)).toBe(10);
  });

  test("addition of 100, 50, 20, 45 and 30 to equal 245", () => {
    expect(additionCalculator(100, 50, 20, 45, 30)).toBe(245);
  });

  test("addition of 7 to equal 7", () => {
    expect(additionCalculator(7)).toBe(7);
  });

  test("addition of no argument provided to equal 0", () => {
    expect(additionCalculator()).toBe(0);
  });
});

Note that the describe() method we used in the snippet above is optional code—it helps organize related test cases into groups.

describe() accepts two arguments:

1. A name you wish to call the test case group—for instance, "additionCalculator's test cases".
2. A function containing your test cases.

Step 13: Refactor the program

So, now that you've refactored your test code, let's do the same for the additionalCalculator program.

// additionCalculator.js

function additionCalculator(...numbers) {
  return numbers.reduce((sum, item) => sum + item, 0);
}

module.exports = additionCalculator;

Here's what we did in the snippet above:

1. The ...numbers code used JavaScript's rest operator (...) to put the function's arguments into an array.
2. The numbers.reduce((sum, item) => sum + item, 0) code used JavaScript's reduce() method to sum up all the items in the numbers array.

Step 14: Rerun the test

Once you've finished refactoring your code, rerun the test to confirm that your program still works as expected.

And that's it!

Congratulations! You've successfully used Jest to develop an addition calculator program using a test-driven development approach! 🎉

Important Stuff to Know about Using ES6 Modules with Jest

Jest does not currently recognize ES6 modules.

However, suppose you prefer to use ES6's import/export statements. In that case, do the following:

1. Install Babel as a development dependency

npm install @babel/preset-env --save-dev

Or, you can use Yarn:

yarn add @babel/preset-env --dev

2. Create a .babelrc file in your project's root

touch .babelrc

3. Open the .babelrc file and replicate the code below

{ "presets": ["@babel/preset-env"] }

The configuration above will now allow you to change step 9's require() statement from this:

const additionCalculator = require("./additionCalculator");

...to this:

import additionCalculator from "./additionCalculator";

Likewise, you can now also substitute step 10's export statement from this:

module.exports = additionCalculator;

...to this:

export default additionCalculator;

Note: Jest also specified similar instructions in their using Babel documentation.

4. Rerun the test

You can now rerun the test to confirm that your program still works!

So, now that we know what test-driven development is, we can discuss its advantages.

What Are the Advantages of Test-Driven Development?

Below are two main advantages of adopting test-driven development (TDD) in your programming workflow.

1. Understand your program's purpose

Test-driven development helps you understand the purposes of your program.

In other words, since you write your test before the actual program, TDD makes you think about what you want your program to do.

Then, after you've documented the program's purposes using one or more tests, you can confidently proceed to create the program.

Therefore, TDD is a helpful way to jot down the specific results you expect your intended program to produce.

2. Confidence booster

TDD is a benchmark for knowing that your program is working as expected. It gives you the confidence that your program is working correctly.

Therefore, irrespective of any future development on your codebase, TDD provides an effective way to test if your program is still working appropriately.

Let's now discuss some popular TDD terms: "unit test," "integration test," "E2E," and "test doubles."

What is a Unit Test in Test-Driven Development?

A unit test is a test you write to assess the functionality of an independent piece of a program. In other words, a unit test checks if a fully isolated unit of program is working as intended.

The test we wrote for step 10's additionalCalculator program is an excellent unit test example.

Step 10's additionalCalculator()'s test is a unit test because the program is an independent function that does not depend on any external code.

Note that a unit test's primary purpose is not to check for bugs. Instead, a unit test's core purpose is to check whether an independent piece of program (called unit) behaves as intended under various test cases.

What is an Integration Test in Test-Driven Development?

An integration test assesses the functionality of a dependent piece of program. In other words, an integration test checks if a program—which depends on other code—is working as intended.

The test we wrote for step 13's additionalCalculator program is an excellent example of an integration test.

Step 13's additionalCalculator()'s test is an integration test because the program is a dependent function that depends on JavaScript's reduce() method.

In other words, we used the prewritten test case to assess the integration of additionalCalculator() and reduce().

Therefore, suppose JavaScript makes reduce() an obsolete method. In such a case, additionalCalculator will fail its test because of the reduce() method.

What is an End-to-End Test in Test-Driven Development?

An End-to-End (E2E) test assesses the functionality of a user interface. In other words, E2E checks if your user interface is working as intended.

Watch Max's YouTube video for a good illustration of an End-to-End test.

What are Test Doubles in Test-Driven Development?

Test doubles are the imitation objects used to mimic real dependencies like databases, libraries, networks, and APIs.

A test double allows you to bypass the natural objects on which your program depends. They let you test your code independently of any dependencies.

For instance, suppose you need to verify if an error detected in your app originates from an external API or your code.

But suppose the API's service is available only in production—not in the development environment. In that case, you've got two options:

1. Wait until your app goes live—which could take months.
2. Clone the API so you can continue your test irrespective of the dependency's availability.

Test doubles provide a helpful way to clone your program's dependencies so that your testing activities won't encounter any disruptions.

Typical examples of test doubles are dummy objects, mocks, fakes, and stubs. Let's discuss them below.

What is a dummy in test-driven development?

A dummy is a test double used to mimic the value of a specific dependency.

For instance, suppose your app depends on a third-party method that requires you to provide some arguments. In such a case, a dummy allows you to pass in pretend values to the parameters of that method.

What is a mock in test-driven development?

Mock is a test double used to mimic an external dependency without considering the responses the dependency may return.

For instance, suppose your app depends on a third-party API (for example, Facebook)—which you cannot access in the development mode. Mock allows you to bypass the API so that you can focus on testing your code regardless of the Facebook API's availability.

What is a stub in test-driven development?

A stub is a test double used to mimic an external dependency while returning hand-coded values. You can use the returned value to assess your program's behavior with various test case responses from the dependency.

For instance, suppose your app depends on a third-party API (for example, Facebook)—which you cannot access in the development mode. Stub allows you to bypass the API while mimicking the exact values Facebook will return.

Therefore, stub helps you assess your program's behavior with various response scenarios.

What is a fake in test-driven development?

Fake is a test double used to create a working test implementation of an external dependency with dynamic values.

For instance, you can use fake to create a local database that allows you to test how a real database will work with your program.

Quick Overview of Test-Driven Development So Far

We've learned that test-driven development helps you jot down your program's behavior before creating the program.

We also saw a simple JavaScript test and used Jest as a test implementation tool.

Let's now see how to test React components.

How to Test React Components

The two main tools you need to test your React components are:

1. A test runner tool
2. A React component testing tool

But what exactly is the difference between a test runner and a React component testing tool? Let's find out.

Test Runner vs. React Component Testing Tool: What's the Difference?

Below are the differences between a test runner and a React component testing tool.

What is a test runner?

A test runner is a tool developers use to run a test script and print the test's results on the command line (CLI).

For instance, suppose you wish to run the test cases in your project's App.test.js test script. In such a case, you will use a test runner.

The test runner will execute App.test.js and print the test's results on the command line.

Typical examples of test runners are Jasmine, Mocha, Tape, and Jest.

What is a React component testing tool?

A React component testing tool provides helpful APIs for defining a component's test cases.

For instance, suppose you need to test your project's <App /> component. In such a case, you will use a React component testing tool to define the component's test cases.

In other words, a React component testing tool provides the APIs for writing your component's test cases.

Typical examples are Enzyme and the React Testing Library.

So, now that we know what a test runner and React component testing tool are, let's use a mini-project to understand how React testing works.

Project: How React Testing Works

In the following steps, we will use Jest and the React Testing Library (by Kent C. Dodds) to learn how React testing works.

Note: The React official docs recommend the Jest and React Testing Library combination for testing React components.

Step 1: Get the right Node and NPM version

Make sure that you have Node 10.16 (or greater) and NPM 5.6 (or greater) installed on your system.

If you prefer to use Yarn, ensure you have Yarn 0.25 (or greater).

Step 2: Create a new React app

Use NPM's create-react-app package to create a new React app called react-testing-project.

npx create-react-app react-testing-project

Alternatively, you can use Yarn to configure your project like so:

yarn create react-app react-testing-project

Step 3: Go inside the project directory

After the installation process, navigate into the project directory like so:

cd react-testing-project

Step 4: Set up your test environment

Install the following test packages:

• jest
• @testing-library/react
• @testing-library/jest-dom
• @testing-library/user-event

Note: If you've initialized your React project with create-react-app (step 2), you do not need to install any of the above packages. They come preinstalled and preconfigured in your package.json file.

Now, let's discuss the purpose of each of the above test packages.

What is Jest?

jest is the test runner tool we will use to run this project's test scripts and print the test results on the command line.

What is @testing-library/react?

@testing-library/react is the React Testing Library which gives you the APIs you need to write test cases for your React components.

What is @testing-library/jest-dom?

@testing-library/jest-dom provides some set of custom Jest matchers for testing the DOM's state.

Note: Jest already comes with lots of matchers, so using jest-dom is optional. jest-dom simply extends Jest by providing matchers that make your test more declarative, clear to read, and easy to maintain.

What is @testing-library/user-event?

@testing-library/user-event provides the userEvent API for simulating users' interaction with your app on a web page.

Note: @testing-library/user-event is a better alternative to the fireEvent API.

Step 5: Clean up the src folder

Delete all files inside the project directory's src folder.

Step 6: Create your code files

Create the following files inside your project's src folder.

• index.js
• App.js
• App.test.js

Step 7: Render the App component

Open your index.js file and render the App component to the DOM like so:

// index.js

import React from "react";
import { createRoot } from "react-dom/client";
import App from "./App";

// Render the App component into the root DOM
createRoot(document.getElementById("root")).render(<App />);

Step 8: Write your test case

Suppose you want your App.js file to render a <h1>CodeSweetly Test</h1> element to the web page. In that case, open your test script and write some test code specifying the result you expect your <App /> component to produce.

Here's an example:

// App.test.js

import React from "react";
import { render, screen } from "@testing-library/react";
import "@testing-library/jest-dom";
import App from "./App";

test("codesweetly test heading", () => {
  render(<App />);
  expect(screen.getByRole("heading")).toHaveTextContent(/codesweetly test/i);
});

Here are the main things we did in the test snippet above:

1. We imported the packages needed to write our test case.

2. We wrote a test case specifying that we expect our <App /> component to render a heading element with a "codesweetly test" text.

3. test() is one of Jest's global methods. We use it to run a test case. The method accepts three arguments:

   • The name of the test ("codesweetly test heading")
   • A function containing the expectations you wish to test
   • An optional timeout argument
4. render() is one of the React Testing Library APIs. We use it to render the component we wish to test.
5. expect() is a Jest method that lets you test the output of your code.
6. screen is a React Testing Library's object containing numerous methods for finding elements on a page.
7. getByRole() is one of the React Testing Library's query methods for finding elements on a page.
8. toHaveTextContent() is one of jest-dom's custom matchers that you can use to confirm the presence of a text content in a specific node.
9. /codesweetly test/i is a regular expression syntax that we used to specify a case-insensitive search for codesweetly test.

Keep in mind that there are three alternative ways to write the above expect statement:

// 1. Using jest-dom's toHaveTextContent() method:
expect(screen.getByRole("heading")).toHaveTextContent(/codesweetly test/i);

// 2. Using the heading's textContent property and Jest's toMatch() method:
expect(screen.getByRole("heading").textContent).toMatch(/codesweetly test/i);

// 3. Using React Testing Library's name option and jest-dom's toBeInTheDocument() method
expect(screen.getByRole("heading", { name: /codesweetly test/i })).toBeInTheDocument();

Tip:

Add a level option to the getByRole() method to specify your heading's level.

Here's an example:

test("codesweetly test heading", () => {
  render(<App />);
  expect(screen.getByRole("heading", { level: 1 })).toHaveTextContent(/codesweetly test/i);
});

The level: 1 option specifies an <h1> heading element.

Suppose you run the test code now. The test will fail because you've not developed the component for which you created the test. So, let's do that now.

Step 9: Develop your React component

Open your App.js file and develop the component to pass the prewritten test.

Here's an example:

// App.js

import React from "react";

const App = () => <h1>CodeSweetly Test</h1>;

export default App;

The App component, in the snippet above, renders a <h1> element containing the "CodeSweetly Test" text.

Step 10: Run the test

Run the prewritten test to check if your program passed or failed.

npm test App.test.js

Alternatively, you can use Yarn like so:

yarn test App.test.js

Once you've initiated the test, Jest will print a pass or fail message on your editor's console. The message will look similar to this:

$ jest
 PASS  src/App.test.js
  √ codesweetly test heading (59 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        3.146 s
Ran all test suites related to changed files.

Note: The create-react-app configured Jest in watch mode by default. Therefore, after running npm test (or yarn test), your currently opened terminal will continue to process the test command's activities. So, you won't be able to input any command on that terminal until you stop test's execution. But you can open a new terminal window simultaneously with the one processing test.

In other words, use one terminal to run test and another to input commands.

Step 11: Run the application

Take a look at your app in the browser by running:

npm start

Or, if your package manager is Yarn, run:

yarn start

Once you run the command above, your app will automatically open on your default browser.

Step 12: Refactor the test code

Suppose you wish to change the heading's text when users click a button. In that case, you can simulate users' interaction with the button to confirm that it works as intended.

Here's an example:

// App.test.js

import React from "react";
import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import "@testing-library/jest-dom";
import App from "./App";

describe("App component", () => {
  test("codesweetly test heading", () => {
    render(<App />);
    expect(screen.getByRole("heading")).toHaveTextContent(/codesweetly test/i);
  });

  test("a codesweetly project heading", () => {
    render(<App />);

    const button = screen.getByRole("button", { name: "Update Heading" });

    userEvent.click(button);

    expect(screen.getByRole("heading")).toHaveTextContent(/a codesweetly project/i);
  });
});

Here are the main things we did in the test snippet above:

1. We imported the packages needed to write our test case.
2. We wrote a test case specifying that we expect the <App /> component to render a heading element with a "codesweetly test" text.
3. We wrote another test case simulating users' interaction with the app's button element. In other words, we specified that whenever a user clicks the button, we expect <App />'s heading to update to "a codesweetly project" text.

Note:

• describe() is one of Jest's global methods. It is optional code that helps organize related test cases into groups. describe() accepts two arguments:
  • A name you wish to call the test case group—for instance, "App component".
  • A function containing your test cases.
• userEvent is the React Testing Library's package containing several methods for simulating users' interaction with an app. For instance, in the snippet above, we used userEvent's click() method to simulate a click event on the button element.
• We rendered <App /> for each test case because React Testing Library unmounts the rendered components after each test. However, suppose you have numerous test cases for a component. In that case, use Jest's beforeEach() method to run render(<App />) before each test in your file (or describe block).

Step 13: Refactor your React component

So, now that you've refactored your test code, let's do the same for the App component.

// App.js

import React, { useState } from "react";

const App = () => {
  const [heading, setHeading] = useState("CodeSweetly Test");

  const handleClick = () => {
    setHeading("A CodeSweetly Project");
  };

  return (
    <>
      <h1>{heading}</h1>
      <button type="button" onClick={handleClick}>
        Update Heading
      </button>
    </>
  );
};

export default App;

Here are the main things we did in the snippet above:

1. App's heading state got initialized with a "CodeSweetly Test" string.
2. We programmed a handleClick function to update the heading state.
3. We rendered a <h1> and <button> elements to the DOM.

Note the following:

• <h1>'s content is the heading state's current value.
• Whenever a user clicks the button element, the onClick() event listener will trigger the handleClick() function. And handleClick will update App's heading state to "A CodeSweetly Project". Therefore, <h1>'s content will change to "A CodeSweetly Project".

Step 14: Rerun the test

Once you've refactored your component, rerun the test (or check the actively running test) to confirm that your app still works as expected.

Afterward, check the browser to see your recent updates.

And that's it!

Congratulations! You've successfully used Jest and the React Testing Library to test a React component. 🎉

Overview

This article discussed how test-driven development works in JavaScript and ReactJS applications.

We also learned how to use Jest and the React Testing Library to make testing simpler and faster.

Thanks for reading!

And here's a useful ReactJS resource:

I wrote a book about React!

• It's beginner friendly ✔
• It has live code snippets ✔
• It contains scalable projects ✔
• It has plenty of easy-to-grasp examples ✔

The React Explained Clearly book is all you need to understand ReactJS.

Test-Driven Development is a much-debated concept in the tech industry. Developers wonder whether they should practice TDD or not, how advantageous it is, and so on.

So what is Test-Driven Development, or TDD? Simply put, TDD dictates that you test your code before you push it to production.

Now, there are a number of opinions for what type of tests you should include in TDD. For example, should you include Unit Tests, Integration Tests, System Tests, or even UAT?

In this article, we will go through a real-world example that'll show you how to write integration tests in .NET 5.0 with a TDD methodology.

For writing tests, we will use the XUnit framework, since it is more extensive than the NUnit or MSTest testing frameworks. Here is a good article if you want to learn more about the difference between these frameworks.

Secondly, VS Code has always been my choice of IDE, but you can use Visual Studio as well.

Let's start by laying out our project requirements.

Project Requirements

TDD requires a very clear understanding of the scope of work. Without that clarity, all the test cases might not be covered.

Let's define what we mean by scope of work. We will be developing a patient admission system for a hospital.

Business Requirements

• A hospital has X ICU rooms, Y Premium rooms, and Z General rooms.
• ICU and Premium rooms can have a single patient at a time, while General rooms can have 2 patients. Each room has a room number.
• On admitting, the patient has to provide name, age, gender, and phone number.
• It is possible to search a patient via name or phone number.
• The same patient cannot be admitted to multiple beds while they are still checked in.
• A patient cannot be admitted if all the rooms are occupied.

Model Validation Rules

Based on the above requirements, there are two models we need to worry about, namely Patient and Room.

• A patient's age is between 0 and 150. The length of their name should be between 2 and 40 characters. Gender can be male, female, and other. Phone Number's length should be between 7 and 12 and it should all be digits.
• Room type can be either "ICU", "Premium" or "General".

Test Cases to implement

Now, that we have defined our rules and requirements, let's start creating test cases. Since it's a basic CRUD application, we will mostly have integration tests.

Patient test cases

• Do all the model validation tests.
• Admit the same patient twice
• Check out the same patient twice.
• Admit the same patient to multiple rooms at the same time.
• Search a patient with phone number and name.

TDD Setup

In the above section we gathered our project requirements. Next we defined the models. Finally, we created the list of test cases which we will implement.

Open your terminal and run the below script to create and setup a new project.

mkdir TDD
cd TDD
dotnet new sln
dotnet new webapi --name TDD
dotnet new xunit --name TDD.Tests
cd TDD
dotnet add package Microsoft.EntityFrameworkCore --version 5.0.5
cd ../TDD.Tests
dotnet add reference ../TDD/TDD.csproj
dotnet add package Microsoft.EntityFrameworkCore --version 5.0.5
dotnet add package Microsoft.AspNetCore.Hosting --version 2.2.7
dotnet add package Microsoft.AspNetCore.Mvc.Testing --version 5.0.5
dotnet add package Microsoft.EntityFrameworkCore.InMemory --version 5.0.5
cd ..
dotnet sln add TDD/TDD.csproj
dotnet sln add TDD.Tests/TDD.Tests.csproj
code .

The above script creates a solution file named TDD.sln. Secondly, we create two projects for TDD and TDD.Tests. Then we add the dependencies for each project. Lastly, we add the projects to the solution and open the project in VS Code.

Before we start testing, we have a bit more setup to do. Basically, integration tests test the a specific module without mocking. So we will be mimicking our application via TestServer.

Custom WebApplicationFactory

In order to mimic the TestServer, there is a class called WebApplicationFactory (WAF) which bootstraps the application in memory.

In your TDD.Tests project create a file named PatientTestsDbWAF.cs with the following code.

using System.Linq;
using Microsoft.EntityFrameworkCore;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Mvc.Testing;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.AspNetCore;


namespace TDD.Tests
{
    public class PatientTestsDbWAF<TStartup> : WebApplicationFactory<TStartup> where TStartup : class
    {

        protected override IWebHostBuilder CreateWebHostBuilder()
        {
            return WebHost.CreateDefaultBuilder()
                .UseStartup<TStartup>();
        }
        protected override void ConfigureWebHost(IWebHostBuilder builder)
        {
            builder.ConfigureServices(async services =>
           {
               // Remove the app's DbContext registration.
               var descriptor = services.SingleOrDefault(
                      d => d.ServiceType ==
                          typeof(DbContextOptions<DataContext>));

               if (descriptor != null)
               {
                   services.Remove(descriptor);
               }

               // Add DbContext using an in-memory database for testing.
               services.AddDbContext<DataContext>(options =>
                  {
                      // Use in memory db to not interfere with the original db.
                      options.UseInMemoryDatabase("PatientTestsTDD.db");
                  });
           });
        }
    }
}

We are removing the application's DbContext and adding an in memory DbContext. This is a necessary step since we don't want to interfere with the original database.

Secondly, we are initialising the database with some dummy data.

Since DataContext is a custom class, it will give compiler error. So we need to create it.

Data Context

In your TDD project, create a file named DataContext.cs with the following code:

using Microsoft.EntityFrameworkCore;

namespace TDD
{
    public class DataContext : DbContext
    {
        public DataContext(DbContextOptions options) : base(options) { }

        // For storing the list of patients and their state
        public DbSet<Patient> Patient { get; set; }

        // For the storying the rooms along with their types and capacity
        public DbSet<Room> Room { get; set; }

        // For logging which patients are currently admitted to which room
        public DbSet<RoomPatient> RoomPatient { get; set; }

    }
}

Here Patient, Room, and RoomPatient are Entity classes with the required properties, which we will create next.

Add the Patient property

Again, in your TDD project, create a file named Patient.cs and paste in the code below:

using System;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace TDD
{
    public class Patient
    {
        [Key]
        [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
        public int Id { get; set; }

        public String Name { get; set; }

        public String PhoneNumber { get; set; }

        public int Age { get; set; }

        public String Gender { get; set; }
    }
}

Add the Room property

Create another file named Room.cs with the following code:

using System;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace TDD
{
    public class Room
    {
          [Key]
        [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
        public int Id { get; set; }

        public String RoomType { get; set; }

        public int CurrentCapacity { get; set; }

        public int MaxCapacity { get; set; }
    }
}

Add the RoomPatient property

Create the last model file RoomPatient.cs with the following code:

using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace TDD
{
    public class RoomPatient
    {
        [Key]
        [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
        public int Id { get; set; }

        [Required]
        public int RoomId { get; set; }

        [ForeignKey("RoomId")]
        public Room Room { get; set; }

        [Required]
        public int PatientId { get; set; }

        [ForeignKey("PatientId")]
        public Patient Patient { get; set; }
    }
}

Now you shouldn't be getting any more compiler errors.

Lastly, remove the WeatherForecast.cs and WeatherForecastController.cs files.

Go to your terminal in VS Code and run the below command:

cd TDD.Tests
dotnet test

You will see a nice green result which says that one test has passed.

Test Success

Create the Patient Controller

Unfortunately .NET doesn't provide a way to directly test the models in itself. So we will have to create a controller to test it.

Go ahead and create a PatientController.cs file in the Controllers folder in TDD project with the below code:

using Microsoft.AspNetCore.Mvc;

namespace TDD.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class PatientController : Controller
    {
        [HttpPost]
        public IActionResult AddPatient([FromBody] Patient Patient)
        {
            // TODO: Insert the patient into db
            return Created("/patient/1", Patient);
        }
    }
}

We created an API to add a patient. In order to test our model we will call this API.

That's all we need to start testing.

Model Validation Tests

Since we've setup the basic code for testing, let's write a test that fails. We will start our testing with the model validation tests.

Failing (Red) State

Let's create a new file named PatientTests.cs in your TDD.Tests project and delete the file named UnitTest1.cs. Copy the below code into your file:

using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Xunit;
using System.Text;
using System.Text.Json;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.AspNetCore.Mvc.Testing;
using System;
using System.Collections.Generic;
using Microsoft.EntityFrameworkCore;

namespace TDD.Tests
{
    public class PatientTests : IClassFixture<PatientTestsDbWAF<Startup>>
    {
        // HttpClient to call our api's
        private readonly HttpClient httpClient;
        public WebApplicationFactory<Startup> _factory;

        public PatientTests(PatientTestsDbWAF<Startup> factory)
        {
            _factory = factory;

            // Initiate the HttpClient
            httpClient = _factory.CreateClient();
        }

        [Theory]
        [InlineData("Test Name 2", "1234567891", 20, "Male", HttpStatusCode.Created)]
        [InlineData("T", "1234567891", 20, "Male", HttpStatusCode.BadRequest)]
        [InlineData("A very very very very very very loooooooooong name", "1234567891", 20, "Male", HttpStatusCode.BadRequest)]
        [InlineData(null, "1234567890", 20, "Invalid Gender", HttpStatusCode.BadRequest)]
        [InlineData("Test Name", "InvalidNumber", 20, "Male", HttpStatusCode.BadRequest)]
        [InlineData("Test Name", "1234567890", -10, "Male", HttpStatusCode.BadRequest)]
        [InlineData("Test Name", "1234567890", 20, "Invalid Gender", HttpStatusCode.BadRequest)]
        [InlineData("Test Name", "12345678901234444", 20, "Invalid Gender", HttpStatusCode.BadRequest)]
        public async Task PatientTestsAsync(String Name, String PhoneNumber, int Age, String Gender, HttpStatusCode ResponseCode)
        {
            var scopeFactory = _factory.Services;
            using (var scope = scopeFactory.CreateScope())
            {
                var context = scope.ServiceProvider.GetService<DataContext>();

                // Initialize the database, so that 
                // changes made by other tests are reset. 
                await DBUtilities.InitializeDbForTestsAsync(context);

                // Arrange
                var request = new HttpRequestMessage(HttpMethod.Post, "api/patient");

                request.Content = new StringContent(JsonSerializer.Serialize(new Patient
                {
                    Name = Name,
                    PhoneNumber = PhoneNumber,
                    Age = Age,
                    Gender = Gender
                }), Encoding.UTF8, "application/json");

                // Act
                var response = await httpClient.SendAsync(request);

                // Assert
                var StatusCode = response.StatusCode;
                Assert.Equal(ResponseCode, StatusCode);
            }
        }
    }
}

The [Theory] attribute allows us to mention different parameters for our tests. Because of this, we don't have to write different tests for all the combinations.

Also, DBUtilities is a utility class to reinitialise the database to its initial state. This might seem trivial when we have 1 or 2 tests, but it becomes critical as we add more tests.

DBUtilities class

The DBUtilities class will initialise your database with 1 patient and 3 different type of rooms.

Create a file named DBUtilities.cs in your TDD.Tests project with the below code:

using System.Threading.Tasks;

namespace TDD.Tests
{
    // Helps to initialise the database either from the WAF for the first time
    // Or before running each test.
    public class DBUtilities
    {

        // Clears the database and then,
        //Adds 1 Patient and 3 different types of rooms to the database
        public static async Task InitializeDbForTestsAsync(DataContext context)
        {
            context.RoomPatient.RemoveRange(context.RoomPatient);
            context.Patient.RemoveRange(context.Patient);
            context.Room.RemoveRange(context.Room);

            // Arrange
            var Patient = new Patient
            {
                Name = "Test Patient",
                PhoneNumber = "1234567890",
                Age = 20,
                Gender = "Male"
            };
            context.Patient.Add(Patient);

            var ICURoom = new Room
            {
                RoomType = "ICU",
                MaxCapacity = 1,
                CurrentCapacity = 1
            };
            context.Room.Add(ICURoom);

            var GeneralRoom = new Room
            {
                RoomType = "General",
                MaxCapacity = 2,
                CurrentCapacity = 2
            };
            context.Room.Add(GeneralRoom);

            var PremiumRoom = new Room
            {
                RoomType = "Premium",
                MaxCapacity = 1,
                CurrentCapacity = 1
            };
            context.Room.Add(PremiumRoom);

            await context.SaveChangesAsync();
        }
    }
}

Go ahead and run the dotnet test command again and you will see 1 passed and 4 failed tests. This is because the 4 tests were expecting BadRequest but were getting a Created result.

Failing (Red) State

Let's fix it!

Success (Green) State

In order to fix these we need to add attributes to our Patient.cs class.

Update the Patient.cs file as below:

using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace TDD
{
    public class Patient : IValidatableObject
    {
        [Key]
        [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
        public int Id { get; set; }

        [Required]
        [StringLength(40, MinimumLength = 2, ErrorMessage = "The name should be between 2 & 40 characters.")]
        public String Name { get; set; }

        [Required]
        [DataType(DataType.PhoneNumber)]
        [RegularExpression(@"^(\d{7,12})$", ErrorMessage = "Not a valid phone number")]
        public String PhoneNumber { get; set; }

        [Required]
        [Range(1, 150)]
        public int Age { get; set; }

        [Required]
        public String Gender { get; set; }

        public Boolean IsAdmitted { get; set; }

        public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
        {
            // Only Male, Female or Other gender are allowed
            if (Gender.Equals("Male", System.StringComparison.CurrentCultureIgnoreCase) == false &&
                Gender.Equals("Female", System.StringComparison.CurrentCultureIgnoreCase) == false &&
                Gender.Equals("Other", System.StringComparison.CurrentCultureIgnoreCase) == false)
            {
                yield return new ValidationResult("The gender can either be Male, Female or Other");
            }

            yield return ValidationResult.Success;
        }
    }
}

Here, we have added the required attributes. We have also implemented the IValidatableObject interface so that we can verify the Gender.

Time to run the dotnet test command. You will see a nice green line saying 5 tests passed.

You can add more edge case scenarios in the InlineData to test the Patient model validation tests thoroughly.

Duplicate Patient Test

We shall now create a test which fails when we try to add a duplicate patient.

Failing (Red) Test

Create another test in your class PatientTests. Add the below code:

[Fact]
public async Task PatientDuplicationTestsAsync()
{
    var scopeFactory = _factory.Services;
    using (var scope = scopeFactory.CreateScope())
    {
        var context = scope.ServiceProvider.GetService<DataContext>();
        await DBUtilities.InitializeDbForTestsAsync(context);

        // Arrange
        var Patient = await context.Patient.FirstOrDefaultAsync();

        var Request = new HttpRequestMessage(HttpMethod.Post, "api/patient");
        Request.Content = new StringContent(JsonSerializer.Serialize(Patient), Encoding.UTF8, "application/json");

        // Act
        var Response = await httpClient.SendAsync(Request);

        // Assert
        var StatusCode = Response.StatusCode;
        Assert.Equal(HttpStatusCode.BadRequest, StatusCode);
    }
}

We have used a [Fact] attribute instead of the [Theory] attribute here since we don't want to test the same method with different parameters. Instead, we want to make the same request twice.

Run dotnet test to run our newly created test. The test will fail with the message Assert.Equal() Failure. Time to fix it.

Success (Green) Test

To fix the failing test we need to add the implementation for the AddPatient method in PatientController.cs. Update the file's code as below:

using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;

namespace TDD.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class PatientController : Controller
    {
        private readonly DataContext _context;

        public PatientController(DataContext context)
        {
            _context = context;
        }
        [HttpPost]
        public async Task<IActionResult> AddPatientAsync([FromBody] Patient Patient)
        {
            var FetchedPatient = await _context.Patient.FirstOrDefaultAsync(x => x.PhoneNumber == Patient.PhoneNumber);
            // If the patient doesn't exist create a new one
            if (FetchedPatient == null)
            {
                _context.Patient.Add(Patient);
                await _context.SaveChangesAsync();
                return Created($"/patient/{Patient.Id}", Patient);
            }
            // Else throw a bad request
            else
            {
                return BadRequest();
            }
        }
    }
}

Run the dotnet test again and you will see that the tests have passed.

Important Notes

As you add more models/domains like Doctors, Staff, Instruments and so on, you will have to create more tests. Make sure to have a different WAF, utility wrappers, and different test files for each of them.

Secondly, the tests in the same file do not run in parallel. But the tests from different files do run in parallel. Therefore, each WAF should have a different database name so that data is not misconfigured.

Lastly, the connections to the original database still need to be setup in the main project.

How to write good tests

The thought process for creating tests for all scenarios is similar.

That is, you should first identify the requirements. Then, set up a skeleton of methods and classes without implementation. Write tests to verify the implementation. Finally, refactor as needed and rerun the tests.

This tutorial didn't include authentication and authorisation for APIs. You can read here on how to set that up.

Since I didn't cover all the test cases here, I have created a repository on Github. It covers the implementation for all the test cases if you want to have a look.

You can find the project here.

Conclusion

In order for TDD to be effective you really need to have a clear idea of what the requirements are. If the requirements keep on changing, it'll become very difficult to maintain the tests as well as the project.

TDD mainly covers unit, integration, and functional tests. You will still have to do UAT, Configuration, and Production testing before you go live.

Having said that, TDD is really helpful in making your project bug free. Secondly, it boosts your confidence for the implementation. You will be able to change bits and pieces of your code as long as the tests pass. Lastly, it provides a better architecture for your project.

Check out more tutorials on .NET here.

This article is part of my studies on how to build sustainable and consistent software. In this post, we will talk about the thinking behind the testing driven development and how to apply this knowledge to simple functions, web accessibility, and React components, mostly with Jest and React Testing Library.

Automated tests are a big part of software development. It gives us, developers, confidence to ship code to be there, but we increase the confidence that the software will be up and running and working appropriately.

I began my software career in the Ruby community writing tests from the first day I learned the language. The Ruby (and Rails) community was always strong in the testing automation area. It helped shape my mindset on how to write good software.

So using Ruby and Rails, I did a lot of backend stuff like background jobs, data structure modeling, API building, and so on. In this scope, the user is always one: the developer user. If building an API, the user would be the developer that's consuming the API. If building the models, the user would be the developer that will use this model.

Now doing a lof of frontend stuff too, after 1 intense year of building PWAs using mostly React and Redux, at first some thoughts came to my mind:

• TDD is impossible when building UI stuff. How do I know if it is a div or span?
• Testing can be "complex". Should I shallow or should I mount? Test everything? Ensure every div should be the right place?

So I started re-thinking about these testing practices and how to make it productive.

TDD is possible. If I'm wondering if I should expect a div or a span, I'm probably testing the wrong thing. Remember: tests should give us the confidence to ship, not necessarily to cover every bit or implementation details. We will dive into this topic later!

I want to build tests that:

• Ensure the software works appropriately
• Give the confidence to ship code to production
• Make us think about software design

And tests that make software:

• Easy to maintain
• Easy to refactor

Testing Driven Development

TDD shouldn't be complex. It is just a process of 3 steps:

• Make a test
• Make it run
• Make it right

We start writing a simple test to cover how we expect the software works. Then we make the first implementation of the code (class, function, script, etc). Now the software is behaving. It works as expected. Time to make it right. Time to make it better.

The goal is a clean code that works. We solve the "that works" problem first and then make the code clean.

It is pretty simple. And it should be. I didn't say it is easy. But it is simple, straightforward, just 3 steps. Every time you exercise this process of writing tests first, code after, and then refactoring, you feel more confident.

One good technique when writing your tests first is to think about use cases and simulate how it should be used (as a function, component, or used by a real user).

Functions

Let's apply this TDD thing into simple functions.

Some time ago I was implementing a draft feature for a real estate registration flow. Part of the feature was to show a modal if the user had a not finished real estate. The function we will implement is the one that answers if the user has at least one real estate draft.

So first step: writing the test! Let's think of the use cases of this function. It always responds a boolean: true or false.

• Has no unsaved real estate draft: false
• Has at least one unsaved real estate draft: true

Let's write the tests that represent this behavior:

describe('hasRealEstateDraft', () => {
  describe('with real estate drafts', () => {
    it('returns true', () => {
      const realEstateDrafts = [
        {
          address: 'São Paulo',
          status: 'UNSAVED'
        }
      ];

      expect(hasRealEstateDraft(realEstateDrafts)).toBeTruthy();
    });
  });

  describe('with not drafts', () => {
    it('returns false', () => {
      expect(hasRealEstateDraft([])).toBeFalsy();
    });
  });
});

We wrote the tests. But when running it, it shows go red: 2 broken tests because we do not have the function implemented yet.

Second step: make it run! In this case, it is pretty simple. We need to receive this array object and return if it has or hasn't at least one real estate draft.

const hasRealEstateDraft = (realEstateDrafts) => realEstateDrafts.length > 0;

Great! Simple function. Simple tests. We could go to step 3: make it right! But in this case, our function is really simple and we've already got it right.

But now we need the function to get the real estate drafts and pass it to the hasRealEstateDraft.

Which use case we can think of?

• An empty list of real estates
• Only saved real estates
• Only unsaved real estates
• Mixed: save and unsaved real estates

Let's write the tests to represent it:

describe('getRealEstateDrafts', () => {
  describe('with an empty list', () => {
    it('returns an empty list', () => {
      const realEstates = [];

      expect(getRealEstateDrafts(realEstates)).toMatchObject([]);
    });
  });

  describe('with only unsaved real estates', () => {
    it('returns the drafts', () => {
      const realEstates = [
        {
          address: 'São Paulo',
          status: 'UNSAVED'
        },
        {
          address: 'Tokyo',
          status: 'UNSAVED'
        }
      ];

      expect(getRealEstateDrafts(realEstates)).toMatchObject(realEstates);
    });
  });

  describe('with only saved real estates', () => {
    it('returns an empty list', () => {
      const realEstates = [
        {
          address: 'São Paulo',
          status: 'SAVED'
        },
        {
          address: 'Tokyo',
          status: 'SAVED'
        }
      ];

      expect(getRealEstateDrafts(realEstates)).toMatchObject([]);
    });
  });

  describe('with saved and unsaved real estates', () => {
    it('returns the drafts', () => {
      const realEstates = [
        {
          address: 'São Paulo',
          status: 'SAVED'
        },
        {
          address: 'Tokyo',
          status: 'UNSAVED'
        }
      ];

      expect(getRealEstateDrafts(realEstates)).toMatchObject([{
        address: 'Tokyo',
        status: 'UNSAVED'
      }]);
    });
  });
});

Great! We run the tests. It doesn't work.. yet! Now implement the function.

const getRealEstatesDrafts = (realEstates) => {
  const unsavedRealEstates = realEstates.filter((realEstate) => realEstate.status === 'UNSAVED');
  return unsavedRealEstates;
};

We simply filter by the real estate status and return it. Great, the tests are passing, the bar is green! And the software is behaving, but we can make it better: step 3!

What about extracting the anonymous function within the filter function and make the 'UNSAVED' be represented by an enum?

const STATUS = {
  UNSAVED: 'UNSAVED',
  SAVED: 'SAVED',
};

const byUnsaved = (realEstate) => realEstate.status === STATUS.UNSAVED;

const getRealEstatesDrafts = (realEstates) => realEstates.filter(byUnsaved);

The tests are still passing and we have a better solution.

One thing to have in mind here: I isolated the data source from the logic. What does it mean? We get the data from local storage (data source), but we test only the functions responsible to the logic to get drafts and see if it has at least one draft. The functions with the logic, we ensure that it works and it is clean code.

If we get the localStorage inside our functions, it becomes hard to test. So we separate the responsibility and make the tests easy to write. Pure functions are easier to maintain and simpler to write tests.

React Components

Now let's talk about React components. Back to the introduction, we talked about writing tests that test implementation details. And now we will see how we can make it better, more sustainable, and have more confidence.

A couple of days ago I was planning to build the new onboarding information for the real estate owner. It is basically a bunch of pages with the same design, but it changes the icon, title, and description of the pages.

I wanted to build just one component: Content and pass the information needed to render the correct icon, title, and description. I would pass businessContext and step as props and it would render the correct content to the onboarding page.

We don't want to know if we will render a div or paragraph tag. Our test needs to ensure that for a given business context and step, the correct content will be there. So I came with these use cases:

• The first step of the rental business context
• Last step of the rental business context
• The first step of the sales business context
• Last step of the sales business context

Let's see the tests:

describe('Content', () => {
  describe('in the rental context', () => {
    const defaultProps = {
      businessContext: BUSINESS_CONTEXT.RENTAL
    };

    it('renders the title and description for the first step', () => {
      const step = 0;
      const { getByText } = render(<Content {...defaultProps} step={step} />);

      expect(getByText('the first step title')).toBeInTheDocument();
      expect(getByText('the first step description')).toBeInTheDocument();
    });

    it('renders the title and description for the forth step', () => {
      const step = 3;
      const { getByText } = render(<Content {...defaultProps} step={step} />);

      expect(getByText('the last step title')).toBeInTheDocument();
      expect(getByText('the last step description')).toBeInTheDocument();
    });
  });

  describe('in the sales context', () => {
    const defaultProps = {
      businessContext: BUSINESS_CONTEXT.SALE
    };

    it('renders the title and description for the first step', () => {
      const step = 0;
      const { getByText } = render(<Content {...defaultProps} step={step} />);

      expect(getByText('the first step title')).toBeInTheDocument();
      expect(getByText('the first step description')).toBeInTheDocument();
    });

    it('renders the title and description for the last step', () => {
      const step = 6;
      const { getByText } = render(<Content {...defaultProps} step={step} />);

      expect(getByText('the last step title')).toBeInTheDocument();
      expect(getByText('the last step description')).toBeInTheDocument();
    });
  });
});

We have one describe block for each business context and an it block for each step. I also created an accessibility test to ensure the component we are building is accessible.

it('has not accessibility violations', async () => {
  const props = {
    businessContext: BUSINESS_CONTEXT.SALE,
    step: 0,
  };

  const { container } = render(<Content {...props} />);
  const results = await axe(container);

  expect(results).toHaveNoViolations();
});

Now we need to make it run! Basically, the UI part of this component is just the icon, the title, and the description. Something like:

<Fragment>
  <Icon />
  <h1>{title}</h1>
  <p>{description}</p>
</Fragment>

We just need to build the logic to get all these correct data. As I have the businessContext and the step in this component, I wanted to just do something like

content[businessContext][step]

And it gets the correct content. So I built a data structure to work that way.

const onboardingStepsContent = {
  alugar: {
    0: {
      Icon: Home,
      title: 'first step title',
      description: 'first step description',
    },
    // ...
  },
  vender: {
    0: {
      Icon: Home,
      title: 'first step title',
      description: 'first step description',
    },
    // ...
  },
};

It's just an object with the first keys as the business context data and for each business context, it has keys that represent each step of the onboarding. And our component would be:

const Content = ({ businessContext, step }) => {
  const onboardingStepsContent = {
    alugar: {
      0: {
        Icon: Home,
        title: 'first step title',
        description: 'first step description',
      },
      // ...
    },
    vender: {
      0: {
        Icon: Home,
        title: 'first step title',
        description: 'first step description',
      },
      // ...
    },
  };

  const { Icon, title, description } = onboardingStepsContent[businessContext][step];

  return (
    <Fragment>
      <Icon />
      <h1>{title}</h1>
      <p>{description}</p>
    </Fragment>
  );
};

It works! Now let's make it better. I wanted to make the get content more resilient. What if it receives a step that doesn't exist for example? These are the use cases:

• The first step of the rental business context
• Last step of the rental business context
• The first step of the sales business context
• Last step of the sales business context
• Inexistent step of the rental business context
• Inexistent step of the sales business context

Let's see the tests:

describe('getOnboardingStepContent', () => {
  describe('when it receives existent businessContext and step', () => {
    it('returns the correct content for the step in "alugar" businessContext', () => {
      const businessContext = 'alugar';
      const step = 0;

      expect(getOnboardingStepContent({ businessContext, step })).toMatchObject({
        Icon: Home,
        title: 'first step title',
        description: 'first step description',
      });
    });

    it('returns the correct content for the step in "vender" businessContext', () => {
      const businessContext = 'vender';
      const step = 5;

      expect(getOnboardingStepContent({ businessContext, step })).toMatchObject({
        Icon: ContractSign,
        title: 'last step title',
        description: 'last step description',
      });
    });
  });

  describe('when it receives inexistent step for a given businessContext', () => {
    it('returns the first step of "alugar" businessContext', () => {
      const businessContext = 'alugar';
      const step = 7;

      expect(getOnboardingStepContent({ businessContext, step })).toMatchObject({
        Icon: Home,
        title: 'first step title',
        description: 'first step description',
      });
    });

    it('returns the first step of "vender" businessContext', () => {
      const businessContext = 'vender';
      const step = 10;

      expect(getOnboardingStepContent({ businessContext, step })).toMatchObject({
        Icon: Home,
        title: 'first step title',
        description: 'first step description',
      });
    });
  });
});

Great! Now let's build our getOnboardingStepContent function to handle this logic.

const getOnboardingStepContent = ({ businessContext, step }) => {
  const content = onboardingStepsContent[businessContext][step];

  return content
    ? content
    : onboardingStepsContent[businessContext][0];
};

We try to get content. If we have it, just return it. If we don't have it, return the first step of the onboarding.

Neat! But we can improve it. What about using the || operator? No need to assign to a variable, no need to use a ternary.

const getOnboardingStepContent = ({ businessContext, step }) =>
  onboardingStepsContent[businessContext][step] ||
  onboardingStepsContent[businessContext][0];

If it finds the content, just return it. If it didn't find, return the first step of the given business context.

Now our component is only UI.

const Content = ({ businessContext, step }) => {
  const {
    Icon,
    title,
    description,
  } = getOnboardingStepContent({ businessContext, step });

  return (
    <Fragment>
      <Icon />
      <h1>{title}</h1>
      <p>{description}</p>
    </Fragment>
  );
};

Final thoughts

I like to think deeply about the tests I'm writing. And I think all developers should too. It does need to give us the confidence to ship more code and have a bigger impact on the market we are working on.

Like all code, when we write smelly and bad tests, it influences other developers to follow the "pattern". It gets worse in bigger companies. It scales badly. But we are always able to stop, reflect on the status quo, and take action to make it better.

I shared some resources I found interesting reading and learning. If you want to get a great introduction to TDD, I really recommend TDD by example, a book from Kent Beck.

I will write more about tests, TDD, and React. And how we can make our software more consistent and feel safe when shipping code to production.

Dependencies

• jest-axe: jest matchers for testing accessibility
• testing-library/react-testing-library: testing utilities to help test react
• testing-library/jest-dom: jest matchers to test the state of the DOM

Resources

• Beginner JavaScript Course
• React for Beginners Course
• Advanced React Course
• ES6 Course
• The Road to learn React
• JavaScript Fundamentals Before Learning React
• Reintroducing React: V16 and Beyond
• Advanced React Patterns With Hooks
• Practical Redux
• JavaScript Course by OneMonth
• Test Driven Development by example book by Kent Beck
• Testable Javascript book by Mark Ethan Trostler
• Blog post source code
• Testing React applications with jest, jest-axe, and react-testing-library
• Modern React testing, part 3: Jest and React Testing Library
• What we found when we tested tools on the world’s least-accessible webpage
• Testing Implementation Details
• Learn React by building an App

You can other articles like this on my blog.

Test Driven Development is hard! This is the untold truth about it.

These days you read a ton of articles about all the advantages of doing Test Driven Development (TDD). And you probably hear a lot of talks at tech conferences that tell you to “Do the tests!”, and how cool it is to do them.

And you know what? Unfortunately, they are right (not necessarily about the “cool” part, but about the useful part). Tests are a MUST! The typical advantages we list when it comes to talking about TDD are real:

• You write better software
• You have protection from breaking the world when new features are introduced
• Your software is self documented
• You avoid over-engineering

Even if I’ve always agreed with these advantages, there was a time when I thought that I didn’t need TDD to write good and maintainable software. Of course, now I know I was wrong, but why did I have this idea despite the shiny magic of the pros? The reason is just one: and let me ask Rihanna to say it for me…

The Cost!

It costs a lot! Probably someone is thinking “but it costs even more if you don’t do the tests” — and this is right, too. But these two costs come at different times:

• you do TDD ➡ you have a cost now.
• You don’t do TDD ➡ you will have a cost in the future.

So, how do we come out of this impasse?

The most effective way to get something done is doing it as naturally as possible. The nature of people is to be lazy (here software developers are the best performers) and greedy, so you have to find your way of reducing the costs now. It’s easy to say, but so hard to do!

Here I will share my experience and what has worked for me in turning the benefit/cost ratio to my favour.

But before I do that, let’s analyze some typical difficulties in applying TDD.

Are you able to test the sum of two numbers?

Generally speaking, theory is not optional; you have to master it in order to master the practice. However trying to apply at once all the theoretical knowledge you’ve previously acquired could have the following effect:

The typical theory lesson on TDD starts with something like this:

And here you are like

Then comes this:

• red ➡ green ➡ refactor cycle
• unit, acceptance, regression, integration tests
• mocking, stubs, fakes
• if you are lucky (or maybe unlucky ?), someone will tell you about contract testing
• and if you are very lucky (or maybe very unlucky ?) you will touch legacy codebase refactoring

The going gets tough, but you are an experienced developer and all these concepts are not that hard to handle for you. Then class ends; you go home, and throughout the next days you diligently do some code katas to fix the concepts just learned. So far so good.

The struggle is real

Next comes a real world project, with real deadlines and real timing costs — but you are motivated to apply your shiny new TDD. You start thinking about the architecture of your software and start writing tests for the first class and the class itself — let’s call it Class1.

Now you think about the first user of Class1, let’s call it UsageOfAClass, and again you test and write it. Class1 is a collaborator of UsageOfAClass, so are you going to mock it? Ok let’s mock it. But what about real interactions of Class1 and UsageOfAClass? Maybe you should test them all as well? Let’s do it.

At this point, inside of you, you start hearing a little voice that says “I would develop much faster if I didn’t have to write these tests…”. You don’t listen to this evil voice and proceed straight to the next test.

Class2 is going to be used by UsageOfAClass and it persists itself inside a Db. So, do we have to test Class2, its interaction with UsageOfAClass, and the persistence in the Db? But wait… did anyone mention how to cope with I/O testing during the TDD theory class?

The theory behind TDD is not that hard to understand, but applying it to the real world can be really complex if you don’t approach it the right way.

Just do it

We should always keep in mind that theory must be bent to our needs and not the contrary.

The main goal is to get the job done. So my advice is, just do it!

Start simple and just do your task up to the end. Then, when you get stuck in some theoretical mind loop like:

• is this a unit or an integration test?
• here should I mock it or not?
• oh crap, here I should write a new collaborator, so a brand new suite of infinite unit tests just to write “hey, banana”…

just forget about theory for a while and take a step forward. Just do it as it comes!

Once you are done with your task, have a look back at your work. Looking back at the completed job, it will be much easier to analyze what would have been the right thing to do.

Practical TDD

Just do it. By the way, I think this is also the right approach to TDD.

What was wrong in how we built Class1, Class2 and UsageOfAClass? The approach.

This is a bottom-up approach:

• analyze the problem
• figure out an architecture
• start building it from unit components

This approach is the best friend of over-engineering. You typically build the system in order to prevent changes that you think will come in the future, without knowing if they actually will. Then when some requirement changes, it typically happens in a way that doesn’t fit your structure, no matter how good it is.

For me the key to drastically reducing the immediate cost of writing with TDD has been to take a top-down approach:

1. bring a user story
2. write a very simple test of a use case
3. make it run
4. go back to step 2 until all use cases are complete

While doing this process, don’t worry too much about architecture, clean code (well, remember at least to use decent variables names) or any kind of complication that is not currently needed. Just do what you know you need now, up to the end.

Tests of the story clearly state what are the current and known requirements.

Once you are done, take a look at your big ball of spaghetti mud code, get over the shame, and look deeper at what you have done:

• it works! And tests prove it.
• All the system is there, and just what is actually needed to get the job done.

Now you have an overview of all the parts of your system, so you can refactor with the knowledge of the domain that you couldn’t have had when you started from scratch. And tests will make sure that nothing will break while refactoring.

Refactoring

The best way for me to start to refactor is to identify areas of responsibility and separate them in private methods. This step helps identify responsibilities and their inputs and outputs.

After that, classes of collaborators are almost there and you just need to move them into different files.

As you proceed, first write tests for the classes that pop out from the process and iterate until you are satisfied with the result. And remember, if you get stuck somewhere, just do it! If you do something bad, once you are done you will have more information on how to get over the mistake the next time you face it. Getting the job done is the priority, to the best of your current abilities.

This way, if you analyze your errors to learn from them, you will also refine your abilities.

The next user story

Continue developing your product following these steps:

• take a story
• make it work completely in a “test — code” cycle.
• refactor

While adding features you will continue to change your software and maybe even its structure. But as the system grows, the cost of change will maintain a linear growth thanks to the two main features of TDD:

• architecture discovery (that helps to control the complexity)
• protection from breaking changes

The system will not be over-engineered, as architecture is going to emerge as stories get completed. You don’t think about what could be future requirements; if you end up needing it, then the cost to implement it will be low.

What can make it go wrong?

The size of the story. What you build up to the end must be the right size. Not too big (otherwise it will take too much time to get any feedback) or too small (otherwise you won’t have the overview).

What if the story is too big? Split it up in pieces that can be built from the start to the end.

What’s next?

In the next article I will give a practical example of the concepts I explained here. We will implement, step by step, the Bowling Game kata starting from an acceptance test.

It is not a real world problem, but it has enough complexity to see how TDD can help in handling it.

Please share your opinion and suggestions about this article. Do you agree with me or do you think that all this is a bunch of rubbish? Let me know what you think in comments; it would be very nice to start a conversation on TDD and share our experiences.

I want to thank Matteo Baglini for helping me to find my way through a practical approach to software development and TDD.

Thank you for reading!

Cover image courtesy of testsigma.

This article is a simple walkthrough of how to apply Test Driven Development (TDD) principles to a JavaScript exercise using Jest.

Intro

After a few years of experience developing on my own personal projects, I recently decided to become a Full-Stack developer.

This new situation encouraged me to start thinking about practices that I’ve neglected until now, such as testing my code.

That is why I wanted to start my journey through Test Driven Development. I’ve decided to share my first steps here with you.

The exercise

I decided to start with the first Osherove TDD kata. You can access the full exercise here.

The goal is to deliver a function that takes a string entry ("1, 2, 3" for instance) and returns the sum of all numbers.

Our project will have the following structure:

js-kata-jest/

├─ src/

  └─ kata.js

├─ test/

  └─ kata.test.js

└─ package.json

Setting up the test environment

First we have to set up the test environment. As a React developer, I decided to go with Jest. You may use any other testing library of your choice.

Installing Jest dev dependency

yarn add --dev jest

or with npm:

npm install --save-dev jest

Activating Jest on your code editor

I am using Atom as a code editor, and installed the tester-jest package. This allowed me to run my tests on save for any *.test.js file.

Test Driven Development

The theory behind TDD is quite simple, and revolves around 3 steps:

1. Writing a test for a small part of a functionality and checking that this new test is failing (Red step)
2. Writing the code that makes the test pass, then checking that your previous test and the new one are successful (Green step)
3. Refactoring the code to make sure it is clear, understandable, and behaves well with the previous functionalities

In the next part, we are going to go into detail for each of these steps.

Solving the exercise

First loop

First, we want to handle the case where our add function is given an empty string or one with a single element.

1. Writing the tests

2. The first test checks that an empty string returns 0

3. The second checks that a single element string returns the provided element

2. Writing the code

• First we return 0 by default
• Then we provide an if statement that handles the parsing of a single provided element

Here is the final code:

3. Refactoring the code

As it is our first functionality, we can skip this step for now — but we will soon return to it. ;)

Second loop

We will now handle the case where the string contains multiple elements:

1. Writing the tests

The new test makes sure that calculation of a multiple element string was done correctly:

2. Writing the code

• First we create a new if statement on purpose to be sure that our first two tests affect the new solution
• Second we create a new array from the entry string, using the , as a separator
• Finally, we parse each element of the newly created array to calculate the sum

Here is the final code:

3. Refactoring the code

As we can see above, there are several problems within our code:

• the two if statement shouldn’t be decorrelated, as adding one or more to zero should behave the same.
• the separator value is drowned in the code. This adds complexity if we want to change to a ; separator, for instance.
• a large part of our code is located in an if statement. We could reverse the logic to extract our main code from it.

So we can add a new separator variable, which will decide on the separator type. We can also merge the two if statement into one, and then reverse the logic.

We can now run our test again before moving on to the next loop.

Third loop

We can now handle the declaration of new separators and avoid the entry of negative numbers.

1. Writing the tests

2. The first new test focuses on a single separator within the default values.

3. The second will make sure that we can configure a new separator directly within the input.
4. The third one will check that an error is thrown when a negative value is passed as an entry.

2. Writing the code

• First, we replace the separator string by a separators array, where we add the \n value.
• Second, we introduce a new separator search through a regular expression. That will be added to the previous array.
• We can now join the previous array elements to split the string with them.
• We filter the resulting array to remove all non-number elements.
• We add a new array, negatives, that will spot negative values within the entry.
• If the negatives array isn’t empty, throw an error.

Here is the final code:

3. Refactoring the code

We now have two new possible optimizations:

• We are using the regular expression twice, and are willing to change it easily. We can extract it within a new const regexp.
• We calculate parseInt(list[i])several times, so we should store the value only once to speed up the for loop.

Conclusion

We can now run our tests again to make sure that all our expected functionalities are still working.

You may now continue on your own as well. Check out the definitive version of the kata with all tests passing here.

Feel free to reach me on Twitter if you have any questions or comments @nclsmitchell or through Medium :)

Thanks for your reading, and please clap for me if you like this post.

When I first wrote about Test-Driven Development, I thought I was in love with the concept… but that was just the flirting stage. Now I’ve fallen head-over-Louboutins, girlfriend! ?

The efficiency gains from not needing to fire my app up for testing are just the beginning. Developing my apps with RSpec forces me to really think about how I’m defining and structuring my code. Furthermore, every time my tests fail, they faithfully supply tips and clues that help me troubleshoot what’s missing, broken or redundant. Now that’s a metaphor for life in general… but I digress. ?

I’m creating an online chess app as part of an agile development team, and this week, I was tasked with building the move_to!(x,y) method. This should move a chess piece (called pawn from now on) to the chessboard square at location (x,y).

If an opponent’s piece (called king from now on) occupies (x,y), pawn should capture it. If pawn’s brother-in-arms occupies (x,y), the method should raise an error message and pawn should go nowhere.

Note: move_to!(x,y) doesn’t consider whether the moves or captures are valid. Other methods will do this.

I configured FactoryBot to generate instances of a chess game. Each chess piece has the following relevant attributes: :location_x, :location_y, :white (a boolean; true = white color), :game_id, and :notcaptured (a boolean; false = the piece has been captured). My first test determined if pawn (currently on 0,0) moved to an empty square (7,7):

Next, I began writing the move_to!(x,y) method, then ran my test:

arit (master) chessapp $ rspec spec/models/piece_spec.rb

.

Finished in 0.43495 seconds (files took 15.68 seconds to load)

1 example, 0 failures

Yes! No errors. ?? Next, I wrote a test to determine whether pawn stayed put if its destination was occupied by a friendly piece (we’ll call it rook):

Why aren’t I testing the values of rook.notcaptured, rook.location_x and rook.location_y? Well, the rook IS the friendly-piece in question, but what we’re actually testing is whatever piece (if any) is found by and saved in the destination variable. Now to flesh out the method:

My tests passed again! ?? Feeling very confident, I moved on to the third test: to determine if the opponent’s king was captured and whether pawn took its place:

I also completed the method:

But when I ran my tests, I received the following error:

arit (master *) chessapp $ rspec spec/models/piece_spec.rb

..F

Failures:

1) Piece captures opponent's piece on destination, then assumes that position

Failure/Error: expect(destination.notcaptured).to be false

expected false

got true

# ./spec/models/piece_spec.rb:104:in `block (2 levels) in <top (required)>'

Finished in 0.21787 seconds (files took 4.83 seconds to load)

1 example, 1 failure

Failed examples:

rspec ./spec/models/piece_spec.rb:95 # Piece captures opponent's piece on destination, then assumes that position

Wha??? destination.notcaptured was not updated? Why? I re-read my method over and over. Nothing seemed to be missing or broken (and, really, just how much could I get wrong in 11 lines of code?).

After deciding to make like a ? and review my rspec test sloooowwly, it occurred to me that the destination variable was expected to change. The move_to!(x,y) method had updated its location_x, location_y and notcaptured attributes.

Then it hit me — I needed to RELOAD destination from the database back into RSpec. Then my three tests passed beautifully:

Test-Driven Development has permanently impacted my coding practice, and I relished the opportunity to turn the rest of my teammates unto it. TDD is lightweight, efficient, safe, revealing, and it helps me produce higher-quality code the first … well, okay… in as little time as possible! ?