feat: Set up tests and add at least one example

[kapobajza]

Hello!

Is your feature request related to a problem? Please describe.

I've seen that people had troubles with setting up tests. So I thought maybe it would be a good idea to add a setup for tests and at least one test which will serve as an example.
The main problem right now with setting up the test environment is that the .env file isn't being loaded, thus an invalid schema error will be thrown.

Describe the solution you'd like to see

In order to fix this problem, the .env (.env.test to be more accurate) has to be loaded. There are several ways to approach this. The first thing the project is missing is a vitest dependency (I assume vitest is a good option) and a vitest.config.ts file.

Then there are 2 ways to load the .env.test file. By adding the vite dependency and using loadEnv:

vite.config.ts

import { defineConfig } from "vitest/config";
import react from "@vitejs/plugin-react";
import { loadEnv } from "vite";

// https://vitejs.dev/config/
export default defineConfig(({ mode }) => {
  // The third argument has to be an empty string, so that properties without the VITE_ prefix are not ignored
  const env = loadEnv(mode, process.cwd(), "");

  // Dirty, because process.env should be read-only
  process.env = Object.assign(process.env, env);

  return {
    plugins: [react()],
    test: {
      environment: "jsdom",
    },
  };
});

Describe alternate solutions

Or another solution would be adding the @next/env dependency and using loadEnvConfig:

vite.config.ts

import { defineConfig } from "vitest/config";
import react from "@vitejs/plugin-react";
import { loadEnvConfig } from "@next/env";

// https://vitejs.dev/config/
export default defineConfig(() => {
  loadEnvConfig(process.cwd());

  return {
    plugins: [react()],
    test: {
      environment: "jsdom",
    },
  };
});

From my point of view this solution is cleaner.

Additional information

What do you think? Should we add tests? If yes, I can take care of it by creating a PR.

And let me know also what do you think about the proposed solutions, because I don't have that much experience with next/trpc/vitest and the T3 stack in general.

Thank you!

[emillindblad]

It would indeed be great with a guide on how to properly set up testing in a T3 app, especially since this snippet exists in the trpc section.

Testing probably wont be included by default or as an option when creating a new project, but a guide for adding testing would be good addition to the docs.

[kapobajza]

It would indeed be great with a guide on how to properly set up testing in a T3 app, especially since this snippet exists in the trpc section.

Testing probably wont be included by default or as an option when creating a new project, but a guide for adding testing would be good addition to the docs.

I agree, a guide would be helpful.
And as you said: testing won't be included by default, but maybe it can be included as an option when scaffolding the app through the CLI.

[juliusmarminge]

Made this yesterday: https://github.com/juliusmarminge/t3-complete

It has both e2e tests with playwright and integration / (unit if u want that) with Vitest.

I didn't bother with ENV so just made a hack around that but should prob do something better that will scale beyond the default env config

[Brian-McBride]

I really appreciate what T3 is providing to the community.

Testing is so important. And the thing developers keep skipping. I get that UX testing is a chore. However, this boilerplate is "full stack," and really, you should learn how to test your TRPC services. Having full test coverage on your hooks and keeping as much business logic in hooks instead of in your views will make a React project much better.

I also suggest tools such as Wallaby.js

A hint from my development teams - build your code in a testing environment. Don't console.log out anything - write an expect test case instead. If you do that, as you go you'll find that most of your unit tests are in place when your finish whatever functional piece of code you were working on. Paid tools like Wallaby really speed up that process as well.

[elliotsayes]

Can I ask the reason this is not planned? Running a basic unit test seems like a must have.

My use case: one of my integrations has broken and my existing API endpoint is not returning helpful information. I want easy way to run some arbitrary code to find the reason. Am I supposed to create a tRPC/API endpoint just to run some test code...?

[Yonben]

Can I ask the reason this is not planned? Running a basic unit test seems like a must have.

My use case: one of my integrations has broken and my existing API endpoint is not returning helpful information. I want easy way to run some arbitrary code to find the reason. Am I supposed to create a tRPC/API endpoint just to run some test code...?

Really wondering the same, unit tests and integration tests to make sure we avoid regressions seems really fundamentals to me as well.

[davidgonmar]

This might help https://www.youtube.com/watch?v=YRGo1H-qNQs

Can I ask the reason this is not planned? Running a basic unit test seems like a must have.

My use case: one of my integrations has broken and my existing API endpoint is not returning helpful information. I want easy way to run some arbitrary code to find the reason. Am I supposed to create a tRPC/API endpoint just to run some test code...?

Can I ask the reason this is not planned? Running a basic unit test seems like a must have.
My use case: one of my integrations has broken and my existing API endpoint is not returning helpful information. I want easy way to run some arbitrary code to find the reason. Am I supposed to create a tRPC/API endpoint just to run some test code...?

Really wondering the same, unit tests and integration tests to make sure we avoid regressions seems really fundamentals to me as well.

[Brian-McBride]

As someone who builds a lot of software for other enterprises, when a client asks me how I am sure what I will deliver to them will work, my answer is automated testing with high code coverage.

All this work for type safety in the T3 repo is excellent. If you do a bit of searching, typed languages vs. dynamic languages didn't have a huge difference in code quality or logic errors. Typescript is fantastic, but if you want quality code - unit tests on the code you write.

Jest is ok. It's gotten better since Facebook let it go. Vitest has some interesting possibilities too. And of course, there are others, but Jest and Vitest seem to be the "React stack" darlings.

[swport]

the stack has a lot of issues with jest and simply doesn't work. examples would be nice.

[swport]

can we at least this answered:
https://stackoverflow.com/questions/76469501/t3-stack-mock-trpc-api-with-jest
??

[victorcarvalhosp]

From my POV this is essential on T3 Stack, at least as an option when creating a new project: Do you want to setup vitest?

[c-ehrlich]

i doubt we will add this. for quick one-offs, tests get in the way. for real projects, you should absolutely set up your testing environment in a way that suits your team and project, not use something a starter gives you. did anyone ever not delete the tests that came with create-react-app? i doubt it... that being said:

• here is an example of using msw-trpc to mock api calls in component tests: https://github.com/c-ehrlich/msw-trpc-example
• playwright works the same as it would in any other next.js app. same with vitest other than the msw setup.
• the story around testing RSCs is still a bit fuzzy. would recommend sticking to e2e for the the time being.
• if you use jest, you're on your own. there is no reason to not use vitest over it at this point. even cpojer, the basically-creator of jest, has said so.

[JohannKaspar]

I am intested in this as well.