Is it possible to use React Testing Library with NEXT_PUBLIC_ environment variables?

[sophiekoonin]

Hey all,

We've got a few Next apps within a monorepo, and we run jest from the root of that repo to run tests for all of those apps. Our tests use react-testing-library (RTL). We're using Next 9.5.2.

I'm trying to replace the older publicRuntimeConfig with the more up-to-date environment variables as suggested in the docs, which is working fine when running the app, but it's broken all our tests. For example, our API path is set with process.env.NEXT_PUBLIC_API_PATH, but when we render a component directly with render from RTL, the API path doesn't get set.

Since we aren't running the Next build process when testing with RTL + Jest, the environment variables don't get substituted for the real deal (so .env.test does not work as suggested in the docs). I've tried to set the env vars explicitly in the test files, but this still isn't working - everything is coming through as undefined.

Is there another way to do component testing while still using Next's environment variables? Should I just go back to using publicRuntimeConfig if I want to use react-testing-library?

Thanks!

[timneutkens]

In the jest setup you can do something like this:

const next = require('next')
const app = next() // Creating the instance of Next.js loads the `.env` files

[jportela]

I was having the same issue and this clarified why .env.test was not loaded.

@sophiekoonin since you mention you are using a monorepo, you'll also have to provide a dir property, for example:

// jest setup file
import next from 'next'
import { resolve } from 'path'
next({
  dir: resolve(__dirname, '../'), // replace `../` with the root of the nextjs project
})

A caveat is that the .next directory needs to be present. If you are running the tests as part of a CI pipeline, you probably are running them before the build step, so you might need to ensure the directory exists before running the test command.

Ultimately, I ended up just loading dotenv on the testing environment, which I found it to be simpler.

@timneutkens I saw the same question on another discussion #16270
Maybe we can add this clarification to the Environment Variables documentation (that the Next instance needs to be created on the Test environment for it to work)? I can submit a PR for that

[timneutkens]

Maybe we can add this clarification to the Environment Variables documentation (that the Next instance needs to be created on the Test environment for it to work)? I can submit a PR for that

Yeah definitely 👍

[weyert]

May I ask a related question? Where you found that publicRuntimeConfig is outdated?
If I read the documentation it does seem to suggest using next/config if you want to be able to change configuration/environment variables without rebuilding the application. Did I misunderstand this? Does this mean using NEXT_PUBLIC_ would not be available in SSG?

Thanks :)