TIL: Using React Testing Library in Vite via Vitest

Vite is a robust tool for rapidly creating React projects. However, unlike Create React App (CRA), Vite does not come with built-in support for React Testing Library (RTL). Let us walk through the process of setting up RTL in a Vite React project using Vitest, a testing solution designed specifically for Vite. By following these steps, you’ll be able to easily write and execute tests for your Vite React applications.

Step 1: Creating a Vite React Project

Let’s begin by creating a new Vite React project. Open your terminal and run the following command:

npm create vite@latest my-vite-app --template react

Step 2: Installing Dependencies

Next, we need to install the necessary dependencies for RTL and Vitest. In your project directory, run the following command:

npm install --save-dev @testing-library/jest-dom @testing-library/react @testing-library/react-hooks @testing-library/user-event jsdom vitest

Step 3: Setting up Vitest

3.1 Create a new file called setupTests.js at the root of your project and add the following import statement:

import "@testing-library/jest-dom"

3.2 Create another file called test-utils.js at the root of your project and include the following code:

/* eslint-disable import/export */

import { render } from "@testing-library/react";

const customRender = (ui, options = {}) =>
  render(ui, {
    wrapper: ({ children }) => children,
    ...options,
  });

export * from "@testing-library/react";
export { default as userEvent } from "@testing-library/user-event";
export { customRender as render };

3.3 Open vite.config.js and add the following code:

export default defineConfig({
  // ...
  test: {
    globals: true,
    environment: 'jsdom',
    setupFiles: './setupTests.js',
  },
})

Step 4: Modifying package.json

Update the scripts section in your package.json file with the following scripts:

"scripts": {
  // ...
  "test": "vitest",
  "coverage": "vitest run --coverage"
}

Step 5: Writing Tests

Now you can start writing tests using RTL in your Vite React project. Here’s an example of a test file named App.test.jsx:

import { describe, expect, it } from "vitest";
import App from "./App";
import { render, screen, userEvent } from "../test-utils";

describe("Sample tests", () => {
  it("should render the title correctly", () => {
    render(<App />);
    const title = screen.getByText(/Welcome to My App/i);
    expect(title).toBeInTheDocument();
  });

  it("should increment count on button click", async () => {
    render(<App />);
    const button = screen.getByRole("button");
    userEvent.click(button);
    const count = await screen.findByText(/Count: 1/i);
    expect(count).toBeInTheDocument();
  });
});

Step 6: Running Tests

To run your tests, execute the following command in your terminal:

npm run test

This is how to set up React Testing Library (RTL) in Vite React projects using Vitest. By following these steps, you can seamlessly integrate testing into your Vite React applications. RTL’s user-friendly API combined with the power of Vit.

Share
TIL: Using React Testing Library in Vite via Vitest

Reflections on the Article “Why Scrum Fails”

Recently, I came across an interesting article titled “Why Scrum Fails.” As someone familiar with agile methodologies and their implementation, I was immediately drawn to the provocative title.

The author begins by questioning the misalignment between the prescribed Scrum process and its actual implementation in organizations. They argue that Scrum has become an oppressive tool for micromanagement, focused solely on story points and velocity. This sentiment resonates with many professionals, including developers, designers, product managers, and middle managers, who have developed a deep disdain for Scrum. It becomes apparent that the real issue lies in the fact that organizations often adopt Scrum while disregarding essential elements crucial for its success.

The article emphasizes the importance of a cross-functional team that possesses all the necessary skills to create value in each sprint. However, in reality, many organizations structure their teams in functional silos, hindering collaboration and inhibiting the delivery of valuable increments. This leads to a shift in focus from customers and value to story points and velocity, ultimately deviating from the core principles of agile development.

The notion of delivering a valuable, useful increment each sprint is pivotal to the Scrum framework. The article highlights the significance of using working software as the primary measure of progress. The failure to continuously deliver valuable software to customers contradicts the essence of agility itself. It becomes evident that organizations often compromise on this critical aspect, viewing themselves as exceptions rather than embracing the transformative potential of Scrum.

The concept of self-managing teams within Scrum also garners attention in the article. The author asserts that true agility necessitates empowering teams to make decisions that contribute to their own success. However, organizations often struggle with defining the role of managers in Scrum, which can inadvertently undermine team autonomy and turn the process into a mechanism of control. The need for a balanced approach to integrate management roles within Scrum becomes evident, where managers can transition into Scrum Masters, product owners, or team members, aligning their skills and interests with the new agile future.

Another thought-provoking aspect discussed in the article is the “Monkey’s Paw Problem” of Scrum. Often, organizations adopt Scrum solely to increase output, viewing it as a means to an end rather than a transformative philosophy. This narrow focus on productivity may lead organizations to resist changes that challenge existing hierarchies or disrupt the status quo. As a result, Scrum becomes a tool to track metrics and maintain output levels, rather than a framework that fosters genuine organizational transformation.

As I progressed through the article, the author raises an intriguing proposition: the potential obsolescence of Scrum. With the advent of continuous delivery, the cycle of inspection and adaptation has become more agile than ever before. The ability to deliver valuable software to customers several times a day challenges the traditional two-week sprint cycle advocated by Scrum. The author suggests exploring agility beyond Scrum, embracing continuous delivery as a more fitting approach that aligns with the values and principles of the Agile Manifesto.

In conclusion, the article provided me with a fresh perspective on the challenges and shortcomings of Scrum. It shed light on the misalignment between the prescribed Scrum process and its actual implementation, as well as the resistance to genuine organizational transformation. It prompted me to question whether Scrum has outlived its usefulness in the face of continuous delivery and whether we should explore agility beyond Scrum.

What are your thoughts on this matter? Have you encountered similar challenges in implementing Scrum? I’m eager to hear your insights. Feel free to share your experiences and perspectives in the comments below.

Share
Reflections on the Article “Why Scrum Fails”