DEV Community: Aleo Yakas

TDD: What's your React-ion?

Aleo Yakas — Tue, 25 Oct 2022 20:51:29 +0000

TL:DR; If our tests are defined by our requirements, we know our application is behaving in the agreed and accepted way when all our tests pass.

A story of two camps

Test Driven Development (TDD) isn't a new practice, but it's certainly a divisive one. There are people who swear that code should only be written to cause tests to pass, while others feel that TDD makes the delivery process more difficult, slowing down the team, while not offering any benefit.

While I see points from both camps, I feel that the naysayers probably haven't approached TDD in the most structured way. I suppose a good question here would be "why do I feel naysayers don't approach TDD in a structured way?" Well, because I'm a former naysayer who didn't approach TDD in a structured way!

Changing camps

I think it's fair to say most people learn to code before they learn to write tests for their code. Because of this, I think most people start their development journey in the "Boo TDD" camp (including me for a while!). Whenever I tried TDD, I came back to the same questions:

How am I expected to know what classes/functions I'm going to be writing?
How am I suppose know what tests to write for code that doesn't exist?

It wasn't until I changed my attitude to testing that I got the answers to my questions and TDD started to working for me.

What were these answers?

In my User Driven Testing post, I outlined why I started treating tests as users of our app. With this shift in mindset, I decided two things:

We don't need to know what code we will write before we write our tests
The tests we need to write were defined the moment we decided how we want our app to function

Was this post written by the Sphinx?

Okay, so what does "The tests we need to write were defined the moment we decided how we want our app to function" mean? Let's work through an example (you can find the source code on my GitHub here).

Let's say we want to build a venue capacity tracker (not a very realistic app to build, but role with me for a second).

We are given the following requirements:

The "Capacity Counter" heading must be present at all times
The user must be able to input a maximum number of people who can enter the venue
The user must click a "Start" button before they can begin recording venue capacity
- If the user enters a non-numeric value for the capacity, a relevant error message should pop up when the user clicks "Start"
- If the user enters a number below 1 for the capacity, a relevant error message should pop up when the user clicks "Start"
- If the user enters a positive numeric for the capacity, the user should be taken to a page to record capacity when they click "Start"
The user should be told what the current visitor count is
The user must be able to add or remove one person from the venue capacity at a time
The user should not be able to reduce the visitor count to below 0
The user should not be able to increase the visitor count above the capacity

The first test before the rest

Before we've even started thinking about writing our code, we can actually start writing our tests. For example, if we want to write a test to verify our first two requirements, we can write something like this:

import React from 'react';
import { render, screen } from '@testing-library/react';
import App from '../src/containers/App';

describe('App', () => {
  test('App loads correctly', () => {
    render(<App />);

    const header = screen.getByRole("heading", { name: /Capacity Counter/i });
    expect(header).toBeVisible();

    const instructions = screen.getByText(/Please provide your venue's capacity./i);
    expect(instructions).toBeVisible();

    const capacityInput = screen.getByRole("textbox", { name: /Capacity/i });
    expect(capacityInput).toBeVisible();
  });
});

With this one test, we've managed to verify our first two requirements. However, it's all well and good verifying the correct content appears on a page, but most apps out there allow users to interact with them to a certain degree.

Are we supposed to just look at a static page?

Let's write some tests for our first bit of behaviour our app will have - inputting our venue's capacity. The first test we want to look at is preventing non-numeric or a negative numbers. We can combined them into a test.each since we want the app to behave in the same way based on these scenarios. We can also write a test to verify the "happy path" - entering a valid capacity.

import React from 'react';
import { render, screen } from '@testing-library/react';
import user from '@testing-library/user-event';
import App from '../src/containers/App';

describe('User can set capacity', () => {
  test.each`
    input    | testDesc
    ${"abc"} | ${"a non-numeric"}
    ${"0"}   | ${"0 for the"}
    ${"-20"} | ${"a negative number"}
  `('User cannot enter $testDesc capacity', ({ input }) => {
    render(<App />);

    const capacityInput = screen.getByRole("textbox", { name: /Capacity/i });
    user.type(capacityInput, input);

    const startBtn = screen.getByRole("button", { name: /Start/i });
    user.click(startBtn);
    expect(startBtn).toBeVisible();

    const errorMsg = screen.getByText(/The capacity you have supplied isn't valid. Please enter a positive number./i)
    expect(errorMsg).toBeVisible();
  });

  test('User can enter a valid numeric capacity', () => {
    render(<App />);

    const setCapacityInstructions = screen.getByText(/Please provide your venue's capacity./i);
    expect(setCapacityInstructions).toBeInTheDocument();

    const capacityInput = screen.getByRole("textbox", { name: /Capacity/i });
    user.type(capacityInput, "25");

    const startBtn = screen.getByRole("button", { name: /Start/i });
    user.click(startBtn);

    expect(setCapacityInstructions).not.toBeInTheDocument();
    expect(capacityInput).not.toBeInTheDocument();
    expect(startBtn).not.toBeInTheDocument();

    const updateVisitorsInstructions = screen
      .getByText(/Update the venue's current visitor count with the buttons below./i)
    expect(updateVisitorsInstructions).toBeVisible();
  });
});

With these 4 tests, we're in a position to confidently say that our app will meet the first 3 points in our requirements. When we come to update our app in future, provided these tests still pass, we know that our app is still meeting its requirements.

Testing our limits

Before you get to the code part of it, I'd like to run you through the last of the tests I wrote for our requirements. We wanted to write tests to: verify we can't set the visitor count below 0; verify we can update the visitor count; and verify we can't set the visitor count above our venue's capacity. We can write these tests like so:

import React from 'react';
import { render, screen } from '@testing-library/react';
import user from '@testing-library/user-event';
import App from '../src/containers/App';

const clickButtonRepeatedly = async (element: HTMLElement, count: number) => {
  for(let i = 0; i < count; i += 1) {
    user.click(element);
  }
}

describe('User can update visitors', () => {
  test('User cannot set visitor count below 0', () => {
    render(<App />);

    const capacityInput = screen.getByRole("textbox", { name: /Capacity/i });
    user.type(capacityInput, "25");

    const startBtn = screen.getByRole("button", { name: /Start/i });
    user.click(startBtn);

    const visitorCount = screen.getByText(/Your venue currently has 0 visitors/i);
    expect(visitorCount).toBeVisible();

    const removeVisitorBtn = screen.getByRole("button", { name: /Remove Visitor/i });
    user.click(removeVisitorBtn);

    expect(visitorCount).toHaveTextContent(/Your venue currently has 0 visitors/i);
  });

  test('User can update capacity', () => {
    render(<App />);

    const capacityInput = screen.getByRole("textbox", { name: /Capacity/i });
    user.type(capacityInput, "25");

    const startBtn = screen.getByRole("button", { name: /Start/i });
    user.click(startBtn);

    const visitorCount = screen.getByText(/Your venue currently has 0 visitors/i);

    const addVisitorBtn = screen.getByRole("button", { name: /Add Visitor/i });
    clickButtonRepeatedly(addVisitorBtn, 10);
    expect(visitorCount).toHaveTextContent(/Your venue currently has 10 visitors/i);

    const removeVisitorBtn = screen.getByRole("button", { name: /Remove Visitor/i });
    clickButtonRepeatedly(removeVisitorBtn, 3);

    expect(visitorCount).toHaveTextContent(/Your venue currently has 7 visitors/i);
  });

  test('User cannot set visitor count above capacity', () => {
    render(<App />);

    const capacityInput = screen.getByRole("textbox", { name: /Capacity/i });
    user.type(capacityInput, "25");

    const startBtn = screen.getByRole("button", { name: /Start/i });
    user.click(startBtn);

    const visitorCount = screen.getByText(/Your venue currently has 0 visitors/i);

    const addVisitorBtn = screen.getByRole("button", { name: /Add Visitor/i });
    clickButtonRepeatedly(addVisitorBtn, 25);
    expect(visitorCount).toHaveTextContent(/Your venue currently has 25 visitors/i);

    user.click(addVisitorBtn);
    expect(visitorCount).toHaveTextContent(/Your venue currently has 25 visitors/i);
  });
});

Focusing on what functionality we have in our app makes writing our tests easier. It also gives us more confidence in our application before we've even started writing the code for it.

ℹ️ Note: You'll notice that I created a util function called clickButtonRepeatedly to save us having to manually click our buttons 25 times. I'd definitely encourage you to write util functions for any test functions you find repeating. Just make sure to test them!

Conclusion

Did you notice how when I said "Before you get to the code part of it", I didn't say "we"? That's because we're not going to look at my code! Instead, I'd like you to clone the repository where I'm hosting these tests and write the code get the tests passing as I've written them.

If you find that easy, you can try meeting these additional requirements we defined in a TDD approach:

When the venue is above 80% capacity, a warning must appear informing the user how many more people are allowed in
At 100% capacity, a severe warning must appear informing the user no more people are allowed in

The tests you write may not be unit tests, but they should still cover the branching pathways of your code.

By writing our tests from this perspective, we've seen if our tests are defined by our requirements, we know our application is behaving in the agreed and accepted way when all our tests pass.

User Driven Testing (UDT)

Aleo Yakas — Tue, 11 Oct 2022 13:33:18 +0000

TL:DR; Our integration tests should mimic our users' behaviour. Our users don't care how our features are implemented, so neither should our tests.

What is it and why do we have a new acronym?

Everyone in tech loves a good acronym - or at least I hope so with how many the tech community have floating around! Why not add User Driven Testing (UDT) to the list? 👀

I had the idea to write this article after attending two workshops: Kateryna Porshnieva's Comprehensive guide to testing React applications workshop and Sandrina Pereira's Web Accessibility in React Apps workshop. I’d already been tackling the best way to structure tests for a new React application my company was working on and I kept coming to the same conclusion - our tests were just users of our application... so why don't we write our tests to behave as users?

Why did I write this article?

Note: This blog post uses a React app as an example, but I do believe that the principles of this blog are applicable when coming to testing any application.

If you were trying to figure out how to test your React application, you would probably find yourself reading React's documentation on testing. You would then probably read about React Testing Library (RTL, for the acronym aficionados). You would then probably read RTL's Guiding Principles. And you would then come across a tweet that makes so much sense that you don't know why you didn't think of it before.

// Detect dark theme var iframe = document.getElementById('tweet-977018512689455106-905'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=977018512689455106&theme=dark" }

At the time, I was setting up a new React app for my company. I now knew what I wanted to achieve: a test suite that mimicked how our users would interact with our app, but it wasn't obvious to me how I could achieve it.

As our app evolved, components were refactored, business logic kept being moved around, and, as a results, our tests were often being rewritten.

"But hang on... When you were doing all these refactors, did the users' behaviour with the application change?" Nope. The users still have the same experience... So why did we have to rewrite our tests?

What was the 'eureka!' moment?

If you're not familiar with RTL, RTL renders the component and all its dependencies to mimic the DOM tree rendered by the browser. That basically means that if a bug is introduced in a dependency of a component being tested, there is a chance the components tests will fail. I know what you’re thinking... "Aleo, if RTL renders a component's children, wouldn't that make the tests... integration tests?" Yes, it would! And that's when it got me thinking - we want our tests to pass if the feature in our app is working, we don’t really care which component is responsible for our feature, do we? So the solution is simple - we want to render our App component in all our tests! Right?

Well... no. If we render our App component, we could have to complete prerequisite tasks repeatedly (like navigating to the page the feature is on) before we even start testing the feature in question. Well why can't we come to a middle ground and just render the component that represents our page?

Bringing theory to practice

We've spoken a lot about the theory, but theory can only go so far - let's have a look at an example (you can find the source code on my GitHub here).

For this example, we've been asked to update our company's ticket booking app. When the app was built, the company was only running holding one event at a time. The company now wants to run multiple events and users should be able to book tickets onto all of them. We've been tasked with refactoring the code to allow users to book on as many events as they would like.

What you're starting with

The (oversimplified) app is composed of two components:

App
Event

The App component looks like so:

import React, { FC } from 'react';
import Event from '../Event';
import styles from './App.module.css';

const App: FC = () => {
  return (
    <div className={styles.container}>
      <h1>User Driven Testing</h1>
      <Event />
    </div>
  );
};

export default App;

and the Event component looks like so:

import React, { FC, useState } from 'react';
import purchaseTickets from '../../requests/purchaseTickets';
import joinClasses from '../../utils/joinClasses';
import styles from './Event.module.css';

const Event: FC = () => {
  const [ticketCount, setTicketCount] = useState(0);

  const increaseTicketCount = () =>
    setTicketCount((currentValue) => currentValue + 1);

  const decreaseTicketCount = () => {
    if (ticketCount > 0) {
      setTicketCount((currentValue) => currentValue - 1);
    };
  };

  const resetTicketCount = () =>
    setTicketCount(0);

  return (
    <div className={styles.container}>
      <h2>Super cool event!</h2>
      <div className={styles.btnGroup}>
        <button 
          onClick={decreaseTicketCount}
          className={joinClasses([styles.btn, styles.btnSecondary])}
        >
          Remove
        </button>
        <p>{ticketCount}</p>
        <button
          onClick={increaseTicketCount}
          className={joinClasses([styles.btn, styles.btnSecondary])}
        >
          Add
        </button>
      </div>
      <div className={styles.btnGroup}>
        <button
          onClick={resetTicketCount}
          className={joinClasses([styles.btn, styles.btnSecondary])}
          aria-disabled={!ticketCount}
        >
          Empty basket
        </button>
        <button
          onClick={() => purchaseTickets(ticketCount)}
          className={joinClasses([styles.btn, styles.btnPrimary])}
        >
          Purchase
        </button>
      </div>
    </div>
  );
};

export default Event;

The first thing you notice is that the "Purchase" and "Empty" checkout buttons are in the Event component. You're aware you're going to have to refactor the code to allow you to add more events.

Before you start refactoring the code, you decide to look at the tests; the App test are minimal at best:

import { render, screen } from '@testing-library/react';
import App from '.';

describe('App', () => {
  test('App loads correctly', () => {
    const { container } = render(<App />);

    expect(screen.getByRole('heading', { name: /User Driven Testing/i })).toBeVisible();
    expect(container.firstChild.children.length).toBe(2);
  });
});

but the Event tests look quite detailed:

import { render, screen } from '@testing-library/react';
import user from '@testing-library/user-event';
import Event from '.';
import purchaseTickets from '../../requests/purchaseTickets';

jest.mock('../../requests/purchaseTickets');
const purchaseTicketsMock = purchaseTickets as jest.Mock;

beforeEach(() => {
  purchaseTicketsMock.mockReset();
});

describe('Event', () => {
  test('Event loads correctly', () => {
    render(<Event />);

    expect(screen.getByRole('heading', { name: /Super cool event!/i })).toBeVisible();
    expect(screen.getByRole('button', { name: /Remove/i })).toBeVisible();
    expect(screen.getByRole('button', { name: /Add/i })).toBeVisible();
    expect(screen.getByRole('button', { name: /Empty basket/i })).toBeVisible();
    expect(screen.getByRole('button', { name: /Purchase/i })).toBeVisible();
  });

  test('tickets can be added', () => {
    render(<Event />);

    const addBtn = screen.getByRole('button', { name: /Add/i });
    const ticketTotal = screen.getByText('0');

    user.click(addBtn);
    expect(ticketTotal).toHaveTextContent('1');

    user.click(addBtn);
    expect(ticketTotal).toHaveTextContent('2');
  });

  test('tickets can be reduced down to 0', () => {
    render(<Event />);

    const addBtn = screen.getByRole('button', { name: /Add/i });
    const removeBtn = screen.getByRole('button', { name: /Remove/i });
    const ticketTotal = screen.getByText('0');

    user.click(addBtn);
    expect(ticketTotal).toHaveTextContent('1');

    user.click(removeBtn);
    expect(ticketTotal).toHaveTextContent('0');

    user.click(removeBtn);
    expect(ticketTotal).toHaveTextContent('0');
  });

  test('empty basket button sets ticket count to 0', () => {
    render(<Event />);

    const addBtn = screen.getByRole('button', { name: /Add/i });
    const emptyBasketBtn = screen.getByRole('button', { name: /Empty basket/i });
    const ticketTotal = screen.getByText('0');

    user.click(addBtn);
    expect(ticketTotal).toHaveTextContent('1');

    user.click(addBtn);
    expect(ticketTotal).toHaveTextContent('2');

    user.click(emptyBasketBtn);
    expect(ticketTotal).toHaveTextContent('0');
  });

  test('purchase button calls purchaseTickets', () => {
    render(<Event />);

    const addBtn = screen.getByRole('button', { name: /Add/i });
    const purchaseBtn = screen.getByRole('button', { name: /Purchase/i });
    const ticketTotal = screen.getByText('0');

    user.click(addBtn);
    expect(ticketTotal).toHaveTextContent('1');

    user.click(addBtn);
    expect(ticketTotal).toHaveTextContent('2');

    user.click(purchaseBtn);
    expect(purchaseTicketsMock).toHaveBeenCalledWith(2);
  });
});

Time for a refactor

You decide to create an EventsGroup component which will be responsible for rendering all your Event components and rendering your "Purchase" and "Empty" buttons. Your EventsGroup component ends up looking something like this:

import React, { FC, useState } from 'react';
import purchaseTickets from '../../requests/purchaseTickets';
import Button from '../../components/Button';
import Event from '../../components/Event';
import styles from './EventsGroup.module.css';

const EventsGroup: FC = () => {
  const ticketCountInit = {
    superCoolEvent: 0,
    anotherAmazingEvent: 0,
  }
  const [ticketCount, setTicketCount] = useState<Record<string, number>>(ticketCountInit);

  const totalTicketCount = Object.values(ticketCount)
    .reduce((total, current) => total + current, 0);

  const increaseTicketCount = (eventKey: string) => () =>
  setTicketCount((currentValue) => ({
    ...currentValue,
    [eventKey]: currentValue[eventKey] + 1,
  }));

  const decreaseTicketCount = (eventKey: string) => () => {
    if (ticketCount[eventKey] > 0) {
      setTicketCount((currentValue) => ({
        ...currentValue,
        [eventKey]: currentValue[eventKey] - 1,
      }));
    };
  };

  const resetTicketCount = () =>
    setTicketCount(ticketCountInit);

  return (
    <div className={styles.container}>
      <Event
        eventName="Super Cool Event!"
        ticketCount={ticketCount.superCoolEvent}
        increaseTicketCount={increaseTicketCount('superCoolEvent')}
        decreaseTicketCount={decreaseTicketCount('superCoolEvent')}
      />

      <div className={styles.btnGroup}>
        <Button
          onClick={resetTicketCount}
          isAriaDisabled={totalTicketCount <= 0}
          variant="secondary"
        >
          Empty basket
        </Button>
        <Button
          onClick={() => purchaseTickets(totalTicketCount)}
          variant="primary"
        >
          Purchase
        </Button>
      </div>
    </div>
  );
};

export default EventsGroup;

And your Event component ends up looking like this:

import React, { FC } from 'react';
import Button from '../Button';
import styles from './Event.module.css';

interface Props {
  eventName: string
  ticketCount: number
  increaseTicketCount: () => void
  decreaseTicketCount: () => void
};

const Event: FC<Props> = ({
  eventName,
  ticketCount,
  increaseTicketCount,
  decreaseTicketCount
}) => {
  return (
    <div className={styles.container}>
      <h2>{eventName}</h2>
      <div className={styles.btnGroup}>
        <Button 
          onClick={decreaseTicketCount}
          variant="secondary"
          isAriaDisabled={ticketCount <= 0}
        >
          Remove
        </Button>
        <p>{ticketCount}</p>
        <Button
          onClick={increaseTicketCount}
          variant="secondary"
        >
          Add
        </Button>
      </div>
    </div>
  );
};

export default Event;

Amazing! You've refactored your code and it's functionally the same! It looks the same in the browser, you can still add/remove tickets exactly the same, and we can easily add as many events as we like in future! So as far as you're concerned, you're job is done! Right?

Well... we've forgotten an important step: to run our tests. We may have forgotten, but our pipeline hasn't - and our pipeline is not happy. All our tests are failing. But why? The code is functionally the same?

But why didn't our tests pass?

"I would have gotten away with it too, if it weren't for you meddling tests!" ~some Scooby Doo antagonist

So our tests aren't passing, everyone in our team has seen, and we're extra annoyed because the app works exactly the same. How can we fix this? Or better yet, how could we have avoided this?

If we want to fix this, there is a simple solution of updating our unit tests. But should our tests really be breaking if the app works the same?

An alternative (and, by me writing this article, my obvious preferred approach) is to convert our unit tests to integration tests. These integration tests will allow us to verify app functions the way we expect and will allow us to refactor our code in future without risk of breaking our tests (ya know, provided we haven't actually broken anything...).

To do this, we can use the test cases defined in our Event test file - but instead of rendering our Event component, we can render our App container. The tests will all pass now! Yay!

Are these really integration tests?

Now I know what you're thinking, "surely that's just an end-to-end test?". Well, while we are testing the all our code in one test file, we should really be seeing it as only testing one feature of our code. In larger code bases, I would not recommend rendering the App component in your integration tests - instead, I would recommend rendering the lowest level container responsible for the feature you're testing (in this case, we actually could render EventsGroup instead, but we didn't have this component at the start).

Location, location, location

Where we store our tests in all down to personal preference. I prefer to keep my integration tests outside my src folder, some people like to have them within the src folder, and others prefer to have them next to the component they are rendering in the test.

It really is up to you, but I prefer to keep my src folder for functional code and unit tests (yes, I do think we should have unit tests on occasion too).

Conclusion

So we set out to refactor a our company's ticket app but broke our tests because they weren't written from a user's perspective. We've seen that if we had written our tests from a user's perspective, we could have made our refactor and our tests would have confidently told us we haven't broken any features of our app.

I do think it's important to still write unit tests for core pieces of logical code (say, any bespoke hooks you write), but the majority of our testing should be done on an integration level for the most return on investment.

Our primary care is how our users interacts with our app. Our users don't care how our features are implemented, so neither should our tests.