vitest-best-practices

Files (1)

• SKILL.md

SKILL.md (first lines)

# Vitest

Use this skill whenever working with `vitest`.

## Core Principles

Write tests that are:

- Easy to understand
- Independent
- Deterministic
- Focused on behavior
- Fast enough to run frequently
- Resistant to implementation-detail refactors

Prefer simple tests over clever test infrastructure.

Test observable behavior, not internal implementation details.

## Before Writing Tests

Inspect the project first.

Check:

- installed Vitest version
- existing `vitest.config.*`
- test naming/location conventions
- test environment
- setup files
- existing test utilities
- mocking conventions
- React Testing Library usage
- monorepo/test project configuration
- coverage configuration

Follow established good patterns, but do not reproduce poor testing practices simply for consistency.

Do not blindly use APIs from a newer Vitest version.

## Test Structure

Prefer:

```ts
describe("calculateTotal", () => {
  it("returns the total price of all items", () => {
    const result = calculateTotal([
      { price: 10 },
      { price: 20 },
    ])

    expect(result).toBe(30)
  })
})
```

Test names should describe behavior.

Good:

```ts
it("rejects an order when the customer has insufficient credit")
```

Avoid vague names:

```ts
it("works")
it("test order")
it("handles case")
```

Use Arrange / Act / Assert conceptually, but do not add comments for obvious sections unless they improve readability.

## Test Behavior, Not Implementation

Prefer testing:

```ts
expect(result).toEqual(expectedResult)
```

over asserting internal calls that users or consumers do not care about.

Avoid testing:

- private implementation details
- internal variable values
- exact internal function-call sequences
- framework internals

unless those interactions are genuinely part of the contract being tested.

Tests should survive reasonable internal refactoring.

## Test One Behavior

A test should normally verify one coherent behavior.

It may contain multiple assertions when they all describe the same outcome.

Good:

```ts
expect(user.name).toBe("Jack")
expect(user.active).toBe(true)
```

Do not mechanically force one assertion per test.

Also avoid one enormous test that covers many unrelated scenarios.

## Inputs and Edge Cases

Test meaningful boundaries.

For a function like:

From Jack-WebDev/skills, MIT.

More from Jack-WebDev/skills