DEV Community: Juan de Tomaso

Configure Vitest, MSW and Playwright in a React project with Vite and TS - Part 3

Juan de Tomaso — Thu, 10 Oct 2024 19:15:12 +0000

Playwright is a framework-agnostic end-to-end testing (also known as E2E, or integration testing) tool for web apps. Playwright has great developer experience and makes writing good and resilient to changes tests straightforward.

1. Install Playwright

To set up Playwright, run the following command:

npm init playwright@latest

You'll be guided through a setup wizard in your terminal. When prompted with "Where to put your end-to-end tests?", you can set it to src/tests (as recommended in earlier tutorials).

Add Scripts to `package.json`

In your package.json, add the following two scripts for running Playwright tests:

This allows you to run the tests in both development and CI environments.

Playwright Configuration

The playwright.config.ts file should be configured as follows:

Key Changes in the Configuration:

use.baseURL: This sets the base URL of your development server, so you don’t have to write it in every test.
webServer: This block describes how to start your development server. It will reuse an already-running server unless you are in a CI environment.
testDir: The directory where Playwright should look for your E2E tests (in this case, src/tests/e2e).

2. Write an E2E Test

Now you can write an E2E test for a flow in your app. Here’s an example Playwright test:

Check how Playwright has it's own way of intercepting network calls.

3. Running the Test

To run the E2E test, use the following command:

npm run test:e2e:ci

This will execute the test in CI mode, which is useful for automated pipelines.

EXTRA

More often than you'd expect, you’ll need to mock query responses to test different scenarios—not necessarily for development purposes. For example, if the backend isn't ready yet and you need to proceed with a screen but are blocked, setting up MSW in the browser allows you to mock responses and keep moving forward.

If you’ve followed the tutorial up to this point, MSW is already set up for testing in a Node.js environment. Now, we’ll configure MSW as a service worker to intercept queries in the browser. You might wonder why this is necessary if we already have Playwright. While Playwright is more focused on automating tests, think of MSW in this context as a development tool for quick testing.

Let’s configure it:

1. Configure MSW for Browser Testing

So far, MSW has been used to mock API responses in a Node.js environment. Now, let’s set it up for the browser.

Create a new JavaScript module to register the MSW service worker for browser-based tests:

2. Register the Worker in Development Mode

To start the MSW worker when the app is running in development mode, add the following to your app’s root module (e.g., src/main.tsx):

Make sure to set the VITE_API_MOCK environment variable in your .env file:

VITE_API_MOCK="true"

IMPORTANT: The MSW worker and the Playwright worker can interfere with each other, so make sure to disable VITE_API_MOCK when running end-to-end (E2E).

Configure Vitest, MSW and Playwright in a React project with Vite and TS - Part 2

Juan de Tomaso — Thu, 10 Oct 2024 19:14:58 +0000

MSW is a tool that allows you to intercept API calls and modify their responses. This helps you test your app in more realistic scenarios, with different responses.

From a high-level view, MSW lets us intercept API calls in two scenarios:

In the browser: This allows you to mock API responses while you're developing the app, making it easier to test different responses as you write your code.
In a Node.js environment: This is typically the case when running tests, such as with Vitest.

In this section, we'll configure MSW for the second scenario, to mock API calls in a Node.js environment during testing.

1. Step 1

Install MSW as a development dependency and initialize it:

npm install msw --save-dev
npx msw init ./public

Setup Mock Server

Next, under you /tests/mock folder create a mock server that runs in a Node environment for use in your tests:

5. Update the Test Setup

In your test setup file, configure the mock server to start and stop during the testing lifecycle:

This configuration ensures that MSW is properly set up, cleaned up after each test, and the handlers are reset to maintain test isolation.

4. Setting up Handlers

Next, under your /tests/mocks folder setup your handlers. MSW provides handlers for different HTTP methods, like GET, POST, etc. Here's how you can mock the GET request for our API:

and then you set those handlers in your server:

6. Writing Tests

Here’s how you can write tests that use the mocked server and handlers. In ItemList.test.tsx:

Check out that to query the list container I set a data-testid="list"in the container element of that component.

In this example:

We mock the API's GET response using MSW.
We handle both successful and failed API requests.
We test that the UI displays the correct information or error message based on the response.

Let me know if you need any further improvements or explanations!

Configure Vitest, MSW and Playwright in a React project with Vite and TS

Juan de Tomaso — Thu, 10 Oct 2024 19:14:38 +0000

Hi, web traveler! If you're here, it's probably because you understand the importance of good testing—or maybe you're just tired of the QA team pointing out issues. Either way, you're in the right place. This guide will help you configure and integrate tools that cover all the angles of testing your app.

Just a quick reminder of what this tools are:

Vitest: For unit testing. If you've used Jest, this tool is quite similar but powered by the Vite engine.
MSW(Mock Service Worker): A tool that intercepts API calls and changes their response, so you can test different scenarios in your app without relying on real API endpoints.
Playwirght: For end-to-end testing.

For this guide, we'll configure a simple React app with Vite. The app will query the public API of the Art Institute of Chicago, display the items in cards, and, when a user clicks on a card, navigate to a detailed view. If you're curious about the API, check it out here.

You can clone the basic code to start this guide in this repo. Here is a snapshot:

Vitest

We'll start by configuring Vitest. If you’ve set up your app with Vite, you’ll probably want to use Vitest since it has a similar API to Jest but is optimized for the Vite environment. Let’s go step-by-step through the configuration.

1. Install packages

First, install these packages as dev dependencies:

npm install -D @testing-library/react vitest jsdom @types/testing-library__jest-dom @testing-library/user-event

Here is what you have installed:

@testing-library/react: classic library build on top of the DOM Testing LIbrary to work with React components --> it lets you render and query React Components
vitest: test runner --> it runs your tests
jsdom: acts as a lightweight browser, creating an environment that simulates the DOM so you can test DOM-related behavior
@types/testing-library__jest-dom: adds typing
@testing-library/user-event: is partner of @testing-library/react: and adds simulation of user interactions with browser

2. Configure Vite to handle tests with Vitest

Next, modify your vite.config.ts like this:

3. Setup files

Create the setup file we specified in vite.config.ts. Inside src, create tests folder, and inside that, create Setup.ts with the following basic setup:

import { afterEach } from 'vitest';
import { cleanup } from '@testing-library/react';
import '@testing-library/jest-dom';

afterEach(() => {
  cleanup();
});

Now, update your tsconfig.json to include Vitest types:

{
  "compilerOptions": {
    ...
    "types": ["vitest/globals"] 
  }
}

and don't forget to include the scripts in package.json:

{
 "scripts": {
    ...
    "test": "vitest",
    "test:watch": "vitest --watch"
  }
}

4. Utils

This is an extra step, but it’s super helpful to create a utility file for your tests. Inside the tests folder, create a TestUtils.tsx file:

Explanation:

The Wrapper function wraps your components in a BrowserRouter. You can extend this by adding other providers like QueryClientProvider or IntlProvider as needed.
customRender provides this wrapper to the render function, and you can pass additional options as required.
You export the necessary utilities from @testing-library/react.
The setup function simplifies test setup by providing access to userEvent and the custom render function.

5. Testing.

Finally, let’s test our configuration with a basic test in CopyrightWarning.test.tsx`. For examplee:

This should provide a solid guide for integrating Vitest into your project. Next steps will involve configuring MSW and Playwright for complete test coverage. Stay tuned!

Pollux - Text Assistant

Juan de Tomaso — Tue, 04 Apr 2023 20:30:58 +0000

Yes, I know, everywhere you look, there's a new magical thing going on with AI. But hey, it's okay. Two years ago, it was the same with crypto, but let's be honest, there weren't a lot of practical approaches as with AI and the GPT fever.

Having said that, and with my consciousness haunted by FOMO and excitement, I have created this Chrome extension. It's called Pollux and is very practical and easy to use. The API was built in python fastAPI framework and deployed on a DigitalOcean machine. Here is the link to install it.

Here are some interesting use cases:

Use case 1: Suppose you are reading an article on any subject you like (news, blogs, newsletters, etc.) and you come across a paragraph you don't understand or a complex concept. You select it, right-click on the Pollux extension, and choose to explain the selected text as if you were 5 or 12 years old. You can even translate the explanation to other languages.

Use case 2: You select all the text of an article and make a summary in 5 bullet points, 3 tweets, etc. You can choose the format, language, and style.

So, that's it. I hope you find this useful. It will probably become obsolete in a few days given how fast things are changing, but it was fun anyway.

Scopes in Javascript

Juan de Tomaso — Sun, 05 Jul 2020 23:27:26 +0000

In this post I want to explore the scopes in Javascript making a parallelism between Javascript and the principles of federalism in political science.

Let's say that the scope of variables are defined in a similar way to how a jurisdiction works in a federal system such as the one in Argentina or the United States: the global sphere (let's say the National State) sanctions laws that rule over all the sub-national states. Furthermore, the sub-national states dictate laws that rule over their territory, and so on, the counties or interior departments sanction laws that rule over their jurisdictions.
Hence, the scope of the laws rules from top to bottom (National -> State -> County) and not the other way around. A county regulations has no authority at the state level, and a state regulation has no authority at the national level.

The scope of variables in Javascript works the same way: a bind defined at the most global level has “jurisdiction” over the whole program. And so, a bind declared in a function has no global reach. It only has “jurisdiction” within the scope of the function in which it was defined and in functions nested within it. A variable defined in a nested function within another function only has jurisdiction in the scope of the nested function where it was defined, but has no reference in external functions or scopes, just like a county regulation has no authority at the state level.

Finally, it is important to note that the parallelism only occurs when the variables are defined with let or const words. When the variables are defined with the word var it is necessary to look for another scenery because they are visible throughout the whole program, no matter where exactly they are defined.

Hope you find it intresting and useful.

My first web!😭

Juan de Tomaso — Tue, 16 Jun 2020 03:23:15 +0000

This is my first web. Its a simple portfolio of a photographer.

I started with html css and javascript 4 months ago. I was very influent by Jen Simmons design aproach and the Bauhaus.

Hope you enjoy it!