DEV Community: Clément Latzarus

How to test react-router redirection with testing-library

Clément Latzarus — Fri, 21 Aug 2020 11:31:38 +0000

React testing-library is very convenient to test React components rendering from props, fire events and check DOM elements. react-router uses a <Redirect> component to trigger a redirect, but how can we test that this component is called using testing-library?

Let’s say we have a CreateBookForm component that creates a new book. It calls our API when the form is submitted.

// BookCreateForm.js
import React, { useState } from 'react';
import api from './api';

function CreateBookForm() {
  const [title, setTitle] = useState('');

  async function handleSubmit(event) {
    event.preventDefault();
    await api.createBook({ title });
  }

  return (
    <form onSubmit={handleSubmit}>
      <input
        placeholder="Book's title"
        value={title}
        onChange={(event) => setTitle(event.target.value)}
      />
      <button>Create book</button>
    </form>
  );
}

export default CreateBookForm;

It's easy to test that our api is called when the form is submitted with testing-library:

// BookCreateForm.test.js
import React from 'react';
import { render, act, fireEvent, waitFor } from '@testing-library/react';

import BookCreateForm from './BookCreateForm';
import api from './api';

jest.mock('./api');

test('it calls api on form submit', async () => {
  api.createBook = jest.fn(() => Promise.resolve({ id: 1 }));
  const { 
    getByPlaceholderText, getByText, findByDisplayValue 
  } = render(<BookCreateForm />);

  await act(async () => {
    const input = getByPlaceholderText(/Book's title/);
    fireEvent.change(input, { target: { value: 'Yama Loka Terminus' }});
    await findByDisplayValue(/Yama Loka Terminus/);

    const button = getByText(/Create book/);
    fireEvent.click(button);
  });

  expect(api.createBook).toHaveBeenCalledWith({ title: 'Yama Loka Terminus' });
});

Now, let's say we want our component to redirect to the new book page once it's created.

// BookCreateForm.js
import React, { useState } from 'react';
import { Redirect } from 'react-router-dom'

import api from './api';

function CreateBookForm() {
  const [title, setTitle] = useState('');
  const [createdId, setCreatedId] = useState(null);

  async function handleSubmit(event) {
    event.preventDefault();
    const { id } = await api.createBook({ title });
    setCreatedId(id);
  }

  return createdId ?
    <Redirect to={`/book/${createdId}`}/> :
    (
      <form onSubmit={handleSubmit}>
        <input
          placeholder="Book's title"
          value={title}
          onChange={(event) => setTitle(event.target.value)}
        />
        <button>Create book</button>
      </form>
    );
}

export default CreateBookForm;

We'll probably have a router wrapping our form and a BookPage component:

// App.js
function App() {
  return (
    <div className="App">
      <BrowserRouter>
        <Route path="/book/create">
          <BookCreateForm />
        </Route>
        <Route path="/book/:id">
          <BookPage />
        </Route>
      </BrowserRouter>
    </div>
  );
}

Now, our test runner will complain that we use <Redirect> outside of a router, so let's wrap our component test into one.

// BookCreateForm.test.js
// …
import { BrowserRouter } from 'react-router-dom';
// …
  const { 
    container, 
    getByPlaceholderText, 
    getByText, 
    findByDisplayValue 
  } = render(<BrowserRouter><BookCreateForm /></BrowserRouter>);
// …

Everything is working fine, but how can we ensure that our form component is redirecting to the new page after the api's response?

That's a tricky question and I've been struggling with this. I've seen some complex solutions involving creating fake routers or mocking the react-router module. But there's actually a pretty simple way to test this.

If we try to snapshot our component after our API was called, we'll notice that it renders an empty div.

expect(container).toMatchInlineSnapshot(`<div />`);

That's because the redirection indeed happened, but there was no route to redirect to. From the testing-library renderer perspective, they are no routes defined, we just ask it to render and empty router containing the form.

To ensure that our user gets redirected to /book/1 (as the book's id returned by our API mock is 1), we can add a route for that specific url with a simple text as children.

  const { 
    container, 
    getByPlaceholderText, 
    getByText, 
    findByDisplayValue 
  } = render(
    <BrowserRouter>
      <BookCreateForm />
      <Route path="/book/1">Book page</Route>
    </BrowserRouter>
  );

And test that the component rendered the text:

expect(container).toHaveTextContent(/Book page/);

Our final test :

// BookCreateForm.test.js
import React from 'react';
import { render, act, fireEvent } from '@testing-library/react';
import { BrowserRouter, Route } from 'react-router-dom';

import BookCreateForm from './BookCreateForm';
import api from './api';

jest.mock('./api');

test('it calls api on form submit', async () => {
  api.createBook = jest.fn(() => Promise.resolve({ id: 1 }));
  const { 
    container, 
    getByPlaceholderText, 
    getByText, 
    findByDisplayValue 
  } = render(
    <BrowserRouter>
      <BookCreateForm />
      <Route path="/book/1">Book page</Route>
    </BrowserRouter>
  );

  await act(async () => {
    const input = getByPlaceholderText(/Book's title/);
    fireEvent.change(input, { target: { value: 'Yama Loka Terminus' }});
    await findByDisplayValue(/Yama Loka Terminus/);

    const button = getByText(/Create book/);
    fireEvent.click(button);
  });

  expect(api.createBook).toHaveBeenCalledWith({ title: 'Yama Loka Terminus' });
  expect(container).toHaveTextContent(/Book page/);
});

How to run Matomo in a Docker container while passing database credentials as environment variables

Clément Latzarus — Tue, 28 Jan 2020 14:45:17 +0000

In the open-source, privacy focused, web analytics software Matomo, database credentials are stored in the config/config.ini.php file.

If you’re using Docker to run Matomo, you might want to keep your credentials out of the Docker image, because they may vary depending on deployment situations, or because the image is publicly available. One solution for this is to remove the config file from the image and mount it at runtime using the --volume argument.

But it’s likely that only the database credentials change and the many remaining configuration options are identical whether you’re developing locally or deploying in production. A solution for this is to keep your config file in the Docker image, while removing only the database credentials from it and passing them to the docker container as environment variables at run time. This is made easy but EnvironmentVariables plugin.

This tutorial is based on my biblys/analytics project.

1. Dockerfile

Here’s an example Dockerfile (you might already have your own) :

# Extend the official Matomo Docker image
FROM matomo:3.13.0

# Install unzip
RUN apt update && apt install -y unzip

# Download, unzip and install the EnvironmentVariables plugin
RUN curl -o EnvironmentVariables.zip \
      https://plugins.matomo.org/api/2.0/plugins/EnvironmentVariables/download/latest \
      && unzip EnvironmentVariables.zip \
      && rm EnvironmentVariables.zip \
      && mv EnvironmentVariables /usr/src/matomo/plugins

# Bring along our personalized Matomo config file
COPY config.ini.php /usr/src/matomo/config/config.ini.php

2. Matomo config file

Now we need to remove all database credentials from our config.ini.phpfile. The database section should then look like this:

[database]
tables_prefix = "matomo_"

I chose to remove host, port, username, password and dbname but to leave in the config file tables_prefix, as this setting should not vary. But it’s totally up to you which settings you want to keep in the config file and which ones you need to pass as environment variables.

By default, an installed plugin is not activated. We can activate it from the Matomo dashboard, but for this we need to login and thus… we need database connection. Fortunatly, Matomo just add an entry into the Plugins[] array of the config file, so we can do this manually.

[Plugins]
(...)
Plugins[] = "Intl"
Plugins[] = "Marketplace"
Plugins[] = "ProfessionalServices"
Plugins[] = "UserId"
Plugins[] = "EnvironmentVariables" # <= add this line

Our config file is ready and now doesn’t contain any sensitive information, so we can include it our public Docker image or a public git repository (be sure to check that this is true for you, as mine also contain SMTP credentials).

3. Build Docker image

Our Docker image is now ready to be built:

docker build -t my-custom-matomo .

Nothing fancy at this step. This will create our custom Matomo image, including the EnvironmentVariables plugin and our config file. Be sure that your custom config file is in the current directory when running this.

4. Run Docker image

We can now our Docker image while passing database credentials as environment variables.

The EnvironmentVariables plugin follows this convention to read env var: MATOMO_$CATEGORY_$SETTING. This means the host setting in the database section should be passed as a MATOMO_DATABASE_HOST env var.

One way to pass an environment variable to docker run is to use the -e argument, so passing our host and port setting would look like this:

docker run -d -p 8080:80 \
  --env "MATOMO_DATABASE_HOST=mydbhost.somecloud.com" \
  --env "MATOMO_DATABASE_PORT=3354" \
  my-custom-matomo

But a better way, in my opinion, is to create an .env file to include our credentials. In our case, it would look something like:

MATOMO_DATABASE_HOST=mydbhost.somecloud.com
MATOMO_DATABASE_PORT=3354
MATOMO_DATABASE_USERNAME=my-user-name
MATOMO_DATABASE_PASSWORD=r4NdomCh4r4CT3R2
MATOMO_DATABASE_DBNAME=my-custom-matomo

Now we just need to include this file in the current directory when we run docker run and pass it to docker with the --env-file argument.

docker run -d -p 8080:80 \
  --env-file=.env \
  my-custom-matomo

And voila!

6. Bonus!

As mentioned, there might be some other setting that we don’t want to include in a publicly shared config file, like SMTP credentials. We can add them to the .env file following the same convention.

MATOMO_MAIL_HOST=mail.somemailprovider.com
MATOMO_MAIL_POST=465
MATOMO_MAIL_USERNAME=my-user-name
MATOMO_MAIL_PASSWORD=r4NdomCh4r4CT3R2

etc.

Is also like to add the force_ssl setting so I can only enforce SSL in production. Sadly, a current limitation, at the time of writing, of the EnvironmentVariables plugin is that configuration arrays are not supported, although it would be very useful to set trusted_hosts only in production.

Also, it’s worth noting that settings passed as environment variables override settings from the config file, so you could leave your local, non-sensitive, development database credentials in the file and only override them in production with env vars.