Unit Tests with Vitest: Frontend Implementation and Support

Without unit tests with Vitest, refactoring on the frontend is playing Russian roulette. A component that crashes in production can cost 4–8 hours of debugging, and a CI pipeline with Jest can drag out to 15 minutes. Switching to Vitest cuts the run time for 500 tests to 5 seconds locally and 2 minutes in CI—a 75% reduction in CI execution time. Vitest unit tests are built on Vite: it uses a shared dev server, native ESM, and parallel execution by default. Our experience spans over 20 projects where we have implemented Unit tests with Vitest, configured coverage thresholds, and integrated CI. The savings on CI resources can reach $300 per month for mid-sized projects.

How Vitest Solves the Problem of Slow Tests

Without tests, refactoring becomes a lottery. A component that crashes in production means losing 4–8 hours for debugging. Vitest catches regressions at the development stage: hot module replacement (HMR) for tests fires in milliseconds, and you see errors immediately. A typical React component is covered by 5–10 tests that check rendering with different props, event handlers, loading states, and error states. Configure Vitest once, and you get 80% line coverage and 70% branch coverage. This reduces the chance of bugs in production by 90% and speeds up the development of new features by 30%.

Why Vitest is Faster than Jest

Vitest uses a shared dev server with Vite — this gives a 4x speed boost when running 500 tests. Built-in ESM support eliminates the need to transform node_modules, and parallel execution by default distributes the load across CPU cores. As a result, tests don't slow down development but become part of it. We have observed CI time reduction from 12 to 3 minutes on projects with 800+ tests—a 75% reduction. Built-in mock functions and spying make writing tests simpler and faster than in Jest.

Vitest is a blazing fast unit test framework powered by Vite — from the official Vitest documentation (https://vitest.dev).

How We Configure Vitest for Your Project

We start with an audit of your current stack. If you already have Jest — we adapt the configuration. If the project is greenfield — we create a reference setup. A typical config looks like this:

// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
    plugins: [react()],
    test: {
        environment: 'jsdom',
        globals: true,
        setupFiles: ['./src/test/setup.ts'],
        coverage: {
            provider: 'v8',
            reporter: ['text', 'json', 'html'],
            thresholds: { lines: 80, functions: 80, branches: 70 },
        },
    },
});

// src/test/setup.ts
import '@testing-library/jest-dom';
import { cleanup } from '@testing-library/react';
import { afterEach } from 'vitest';

afterEach(() => cleanup());

Comparison of Vitest and Jest

What's Included in the Work to Implement Vitest

We deliver the project with everything necessary:

• Configured Vitest with coverage thresholds (lines 80%, functions 80%, branches 70%)
• Written Unit tests for key components and business logic (at least 10 tests per component)
• Migration from Jest (if needed) with preservation of all existing tests
• Integration into CI (GitHub Actions / GitLab CI) with coverage reports
• Documentation on running tests and adding new ones
• Team training: 2–3 sessions on writing tests with Vitest

Coverage Tools Comparison

Implementation Process

1. Audit — we assess the current code and tests, identify bottlenecks.
2. Setup — install Vitest, write config, mocks, and setup files.
3. Test development — cover key logic: utilities, hooks, components.
4. Migration (optional) — convert Jest tests with minimal edits.
5. CI integration — add test execution to the pipeline and coverage thresholds.
6. Handover — hand over documentation and conduct training.

Why Trust Us with Implementation

Over the course of our work, we have completed more than 20 projects with Unit tests on Vitest. We guarantee that tests will be stable, not flaky. We use proven practices: Vitest is an open-source project with an active community, and we keep track of updates. In a typical React component, we cover: rendering with different props, event handlers, states (empty, loading, error), interaction with hooks (useState, useEffect), and edge cases (null, undefined, boundary values). We also consider Core Web Vitals metrics so that tests not only check logic but also do not worsen LCP and INP.

Timeline and Cost

Basic setup of Vitest plus writing the first batch of tests takes 2–4 days. Migration from Jest takes up to 5 days depending on volume. Cost is calculated individually after an audit. Order an audit and we will select the optimal solution. Get a consultation to evaluate your project. Contact us for details.

Why are unit tests important but not a panacea?

A bug found by a unit test costs minutes to fix. The same bug in production costs hours of incident response, compensations, and lost trust. In an online store project, a discount calculation error passed manual testing, went to production, and processed 37 orders at zero price in 4 hours. An automated test for edge cases would have caught it on the first push. With 7+ years in web application testing and over 200 projects delivered, we’ve seen this pattern repeat across industries.

Jest is the standard for JavaScript/TypeScript, but unit tests are justified only where there is isolated logic: transformation functions, validators, business rules, utilities. Testing React components with Jest + Testing Library is correct for behavioral tests: "button appears after loading", "form shows error on empty email". Snapshot tests (toMatchSnapshot) are a trap: they break on any layout change and become noise that developers update without looking. Code coverage is a poor quality metric: 80% coverage can be achieved with tests that check nothing. Coverage shows that code executed, not that it works correctly.

Vitest as an alternative to Jest for Vite projects: 10–20x faster due to native ES modules without Babel transformation. For monorepos with thousands of tests, the speed difference is noticeable. Wikipedia on unit testing describes the theoretical foundation — we apply it with real CI pipelines.

How to set up E2E tests that are not flaky?

Playwright outperforms Cypress on key parameters: native multi-tab, multi-origin, iframe support; parallel execution at test level; WebKit, Firefox, Chromium out of the box; no iframe for the app — tests run in a real browser.

Playwright codegen records actions and generates a test — a good starting point, but generated code needs refactoring. Locators by text content are fragile: getByRole('button', { name: 'Place order' }) is more robust than locator('.btn-primary').

Page Object Model is the standard for organizing E2E tests. Each page is a separate class with methods instead of direct locators. When a button moves from header to sidebar — change in one place, not across all tests.

Flaky tests typically arise from race conditions between request and render, animations without wait, and dependency on external APIs. Solution: page.waitForResponse() instead of page.waitForTimeout(), mocking external APIs via page.route().

// Bad
await page.click('#submit');
await page.waitForTimeout(2000);
await expect(page.locator('.success')).toBeVisible();

// Good
await page.click('#submit');
await page.waitForResponse(resp =>
  resp.url().includes('/api/orders') && resp.status() === 201
);
await expect(page.getByRole('alert', { name: /order created/i })).toBeVisible();

Our engineers guarantee test stability in CI. Playwright’s official documentation covers all API details — we use it daily on projects with millions of users.

How do Core Web Vitals affect ranking?

Google uses Core Web Vitals in ranking. Lighthouse CLI in CI pipeline: on every deploy we check that LCP < 2.5s, CLS < 0.1, INP < 200ms. Google Chrome study: 53% of users leave a site if it takes longer than 3 seconds to load — our tests prevent such losses.

Real problems that Lighthouse finds:

• Hero image without width/height attributes: CLS 0.35 on load.
• JavaScript bundle 2.1MB synchronously blocking parsing: INP 450ms.
• Fonts without font-display: swap: invisible text until font loads (FOIT).
• Unoptimized hero image 4MB: LCP 8.2s.

Lighthouse CI (lhci) saves metric history and posts a comment to PR with degradation. For one e‑commerce client, optimizing these metrics improved conversion by 18% and reduced server costs by $12k annually.

What does load testing solve?

k6 is a load testing tool with a JavaScript API. Scenarios are written as code, versioned in git, run in CI. Three main scenarios:

• Spike test — sharp load increase: 0 → 1000 users in 30 seconds. Simulates a campaign launch. Shows system's ability to handle spikes.
• Soak test — stable load for 2–4 hours. Detects memory leaks, connection pool exhaustion, performance degradation.
• Stress test — load above expected (150–200% of peak). Shows breaking point and graceful degradation.

Thresholds:

thresholds: {
  http_req_duration: ['p95<500', 'p99<1000'],
  http_req_failed: ['rate<0.01'],
}

p95 < 500ms means 95% of requests respond faster than half a second. If threshold is not met, k6 exits with error code, CI pipeline fails.

In one online store project, we detected API degradation at the 4th hour of the test: p95 increased from 200ms to 2s due to connection leaks. After optimization, the client saved $15k per year on incident response and extra infrastructure.

Testing pyramid in a project

What does the work include?

• Audit of current coverage and identification of critical user flows.
• Writing unit tests for key business logic, integration tests for API, E2E for user scenarios.
• Setting up parallel execution in CI (sharded workers for Playwright).
• Load testing with report and recommendations.
• Test case documentation, training your team on test practices.
• 1-month warranty support after implementation.
• Delivery of all test artefacts (code, CI configs, run histories).

How do we work?

1. Analysis — audit of current testing, identification of weak spots, priority setting.
2. Design — tool selection, test plan writing, approval.
3. Implementation — writing tests, CI integration.
4. Testing — running all levels, result analysis, bug fixing.
5. Deployment — going live, metric monitoring, team training.

Timeline

Setting up a full test pipeline (Jest + Playwright + k6 + Lighthouse CI) from scratch: 2–4 weeks. E2E test coverage of an existing project (20–30 scenarios): 3–6 weeks. Load testing with report and recommendations: 1–2 weeks. Cost calculated individually after audit.

Ready to discuss your project? Leave a request — we will audit your current web application testing for free and propose a plan that can save up to 60% on incident costs. Get a consultation on web application testing — contact us today.