DEV Community: MSakai

Test your FastAPI routes without touching the database

MSakai — Sun, 23 Aug 2026 13:32:21 +0000

The usual first attempt at testing a FastAPI route reaches for patch:

with patch("myapp.routes.get_db") as mock_db:
    response = client.get("/users/1")

It doesn't work, and the reason is instructive. FastAPI resolved Depends(get_db) when the route was registered, at import time. The function object it holds is not the one your patch replaced.

The intended mechanism

FastAPI keeps a mapping on the app for exactly this:

# myapp/deps.py
def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

# tests/conftest.py
import pytest
from fastapi.testclient import TestClient
from myapp.main import app
from myapp.deps import get_db

@pytest.fixture
def client(test_session):
    def override_get_db():
        yield test_session

    app.dependency_overrides[get_db] = override_get_db
    yield TestClient(app)
    app.dependency_overrides.clear()

The key is the function object itself, not a string path. No import-time subtlety, no patch target to get wrong.

That clear() in the teardown matters. app is a module-level singleton shared by every test, so a leftover override silently applies to the rest of the suite.

Where this pays off most: auth

Testing an authenticated route usually means minting a real JWT, which means your route tests now depend on your token library, your clock, and your secret configuration.

def override_current_user():
    return User(id=1, email="test@example.com", is_admin=False)

app.dependency_overrides[get_current_user] = override_current_user

One line, and every protected route is testable. Test the token logic once, directly, in its own file — where it belongs.

Overriding per test, not per suite

Make the override a parameter and you can vary it:

@pytest.fixture
def client_as():
    def _make(user: User):
        app.dependency_overrides[get_current_user] = lambda: user
        return TestClient(app)
    yield _make
    app.dependency_overrides.clear()


def test_admin_can_delete(client_as):
    r = client_as(User(id=1, is_admin=True)).delete("/posts/1")
    assert r.status_code == 204


def test_regular_user_cannot(client_as):
    r = client_as(User(id=2, is_admin=False)).delete("/posts/1")
    assert r.status_code == 403

Two authorisation cases, no tokens, no database.

What to still use a real database for

Overrides are the right tool for routes. They are the wrong tool for anything where the database itself is the thing under test — constraints, cascades, migrations, transaction boundaries.

For those, an in-process SQLite session is usually enough:

@pytest.fixture
def test_session():
    engine = create_engine("sqlite://", connect_args={"check_same_thread": False})
    Base.metadata.create_all(engine)
    with Session(engine) as s:
        yield s

...with the caveat that SQLite will not reproduce Postgres behaviour for JSON columns, array types, or ON CONFLICT specifics. When those matter, reach for a real Postgres in a container and accept the slower feedback loop for that one file.

The distinction worth keeping

Route tests answer "does this endpoint wire up correctly?" Database tests answer "does this data model hold?" Overrides make the first kind fast. Don't use them to avoid writing the second kind.

These posts come out of material I build for my Udemy courses — 25 of them now, mostly drill-based, across Go, Python, TypeScript, testing and Three.js. If this was useful, the full list is at udemy-c1f90.web.app. The links on that page carry a coupon I refresh each month, which usually lands around half the list price.

monkeypatch or mock.patch? One question decides it

MSakai — Fri, 21 Aug 2026 13:45:03 +0000

Both replace an attribute. Both undo it afterwards. Most codebases end up with both, chosen by whichever the author saw last.

There is a cleaner line to draw.

The question

Do you need to assert on how it was called?

No — you just need it to return something, or to not happen. Use monkeypatch.
Yes — you want assert_called_once_with. Use mock.patch / MagicMock.

That covers the great majority of real cases.

When you only need a value

monkeypatch is a pytest fixture. It reads as plain Python, and it undoes everything at the end of the test automatically.

def test_uses_configured_region(monkeypatch):
    monkeypatch.setenv("AWS_REGION", "ap-northeast-1")
    assert build_client().region == "ap-northeast-1"

def test_handles_missing_file(monkeypatch):
    monkeypatch.setattr(Path, "exists", lambda self: False)
    assert load_config() == DEFAULTS

Note setenv and delenv. This is the part mock.patch handles awkwardly (patch.dict(os.environ, ...)) and it comes up constantly.

monkeypatch also has chdir and syspath_prepend, both of which are genuinely painful to do by hand and restore correctly.

When you need to inspect the call

from unittest.mock import patch

def test_sends_welcome_email():
    with patch("myapp.users.send_email") as mock_send:
        register_user("a@example.com")

    mock_send.assert_called_once_with(
        to="a@example.com",
        template="welcome",
    )

monkeypatch.setattr with a plain lambda can't do this. You'd end up hand-rolling a recorder — which is exactly what MagicMock already is.

The mistake both share

Patch where the name is looked up, not where it is defined.

# myapp/users.py
from myapp.email import send_email      # bound at import time

patch("myapp.email.send_email")   # too late, users.py already has its own reference
patch("myapp.users.send_email")   # correct

This trips people up with monkeypatch.setattr in exactly the same way:

monkeypatch.setattr("myapp.users.send_email", fake)   # correct

If the import in the module under test is import myapp.email and the call site is myapp.email.send_email(...), then patching myapp.email.send_email is right — because the lookup happens at call time. The rule is about the lookup, not about the file.

A practical hybrid

You can get monkeypatch's cleanup with MagicMock's assertions:

def test_sends_welcome_email(monkeypatch):
    mock_send = MagicMock()
    monkeypatch.setattr("myapp.users.send_email", mock_send)

    register_user("a@example.com")

    mock_send.assert_called_once_with(to="a@example.com", template="welcome")

No context manager, no decorator stacking, full assertion API. When a test needs three patches, this reads considerably better than three nested with blocks.

The summary

Need	Tool
Environment variables	`monkeypatch.setenv`
Working directory	`monkeypatch.chdir`
Stub a return value	`monkeypatch.setattr`
Assert on arguments	`MagicMock` (installed either way)
Patch across many tests	`patch` as a decorator, or an autouse fixture

Pick per test based on what you're asserting, not per codebase based on convention.

Checking your A/B test every morning makes it lie to you

MSakai — Wed, 19 Aug 2026 13:44:09 +0000

You launch the test on Monday. You check the dashboard each morning, because of course you do. On Thursday it reads p = 0.04, you call it, and you ship.

That p-value did not mean what the tooltip said it meant.

Why looking changes the result

A p-value of 0.05 is a promise about a specific procedure: collect a predetermined sample, then test once. Under that procedure, a true null hypothesis produces a false positive 5% of the time.

Checking repeatedly is a different procedure. The statistic wanders as data accumulates, and each look is another opportunity for that wandering to cross the line. You are not measuring whether the effect is real. You are measuring whether it ever looked real.

What it costs, concretely

Simulate two identical variants — no effect whatsoever — and stop the moment p drops below 0.05:

import numpy as np
from scipy import stats

rng = np.random.default_rng(0)

def run(peeks, n_per_peek=200, trials=10_000):
    false_positives = 0
    for _ in range(trials):
        a, b = [], []
        for _ in range(peeks):
            a.extend(rng.binomial(1, 0.10, n_per_peek))
            b.extend(rng.binomial(1, 0.10, n_per_peek))   # identical
            if stats.ttest_ind(a, b).pvalue < 0.05:
                false_positives += 1
                break
    return false_positives / trials

for p in (1, 5, 10, 20):
    print(f"{p:2d} looks -> {run(p):.1%}")

 1 looks -> 5.0%
 5 looks -> 14.2%
10 looks -> 19.4%
20 looks -> 25.6%

Twenty looks — four weeks of checking on weekdays — and one experiment in four reports a winner that does not exist. Every one of those will be defended with a screenshot showing p < 0.05.

Three ways out

1. Fix the sample size in advance, and don't look.

Compute it before launching, from the smallest effect worth shipping:

from statsmodels.stats.power import NormalIndPower
from statsmodels.stats.proportion import proportion_effectsize

effect = proportion_effectsize(0.10, 0.11)   # 10% -> 11%
n = NormalIndPower().solve_power(effect, power=0.8, alpha=0.05, ratio=1)
print(f"{n:,.0f} per variant")

This is the honest option, and the one most teams skip because the number that comes back is uncomfortably large. That discomfort is the information: it's telling you the effect you're hoping for needs more traffic than you have.

2. Look, but adjust the threshold.

Sequential testing methods — O'Brien-Fleming boundaries, alpha spending — let you monitor while keeping the overall false positive rate at 5%, by demanding much stronger evidence early on.

3. Stop reporting significance at all.

Report the observed difference and a confidence interval. "+1.2% [-0.4%, +2.8%]" communicates both the estimate and the uncertainty, and it doesn't invite a binary ship/don't-ship reading from a number that was never binary.

The one thing that isn't negotiable

Whatever you choose, decide the stopping rule before you see any data. Peeking is only a problem because the decision to stop depends on what you saw. A fixed rule, even a crude one, removes the mechanism entirely.

The uncomfortable implication

Most teams running weekly experiments on modest traffic are underpowered for the effects they're chasing, and their significant results are dominated by this bias. The fix is not a better dashboard. It is running fewer, larger tests on changes big enough to be worth detecting.

The context you passed is not the context that cancels

MSakai — Mon, 17 Aug 2026 13:39:34 +0000

Two failure modes, opposite in effect, same root cause. Both compile, and both are quiet in development.

Failure one: the work dies with the request

func (h *Handler) Create(w http.ResponseWriter, r *http.Request) {
    order := parse(r)
    save(order)

    go func() {
        h.sendConfirmationEmail(r.Context(), order)   // cancelled the moment Create returns
    }()

    w.WriteHeader(http.StatusCreated)
}

r.Context() is cancelled when the handler returns and the response is written. Your goroutine gets a context that is already dead, or dies milliseconds later. Emails silently don't send — and under local testing, where the goroutine usually wins the race, everything looks fine.

Since Go 1.21 the fix is one call:

ctx := context.WithoutCancel(r.Context())
go h.sendConfirmationEmail(ctx, order)

WithoutCancel keeps the values — trace IDs, request-scoped logger, auth subject — while detaching from the parent's cancellation. Before 1.21 you had to hand-roll a context.Background() and re-attach every value you cared about, which is how those values usually got lost.

Give the detached work its own deadline, because it no longer has one:

ctx, cancel := context.WithTimeout(context.WithoutCancel(r.Context()), 30*time.Second)
go func() {
    defer cancel()
    h.sendConfirmationEmail(ctx, order)
}()

Failure two: the cancellation never arrives

func fetchAll(ctx context.Context, ids []string) ([]Item, error) {
    var items []Item
    for _, id := range ids {
        item, err := db.Get(context.Background(), id)   // ignores ctx entirely
        if err != nil {
            return nil, err
        }
        items = append(items, item)
    }
    return items, nil
}

The caller cancels. Nothing stops. The loop runs to completion against a client that hung up, holding a database connection the whole time. Under load this is how a spike in cancelled requests turns into connection pool exhaustion.

The signature accepts a ctx and then ignores it, which is worse than not accepting one — every caller reasonably assumes cancellation works.

Making it visible

go vet catches a lost cancel, but not a lost ctx. Two things that do help:

contextcheck (available via golangci-lint) flags functions that receive a context and then pass context.Background() downstream — exactly failure two.

# .golangci.yml
linters:
  enable:
    - contextcheck
    - noctx        # flags http.NewRequest without a context

A test that asserts cancellation propagates. If it matters, assert it:

func TestFetchAllRespectsCancellation(t *testing.T) {
    ctx, cancel := context.WithCancel(context.Background())
    cancel()

    _, err := fetchAll(ctx, []string{"a", "b", "c"})
    if !errors.Is(err, context.Canceled) {
        t.Fatalf("expected context.Canceled, got %v", err)
    }
}

Pre-cancelling before the call is the cheap version and catches most regressions.

The convention that prevents both

A context is scoped to an operation. When the operation's lifetime changes, the context has to change with it — explicitly.

Concretely:

Work that must outlive the request: context.WithoutCancel, plus a fresh timeout
Work that is part of the request: pass ctx down, unchanged, to every call that accepts one
context.Background() appears in main, in tests, and essentially nowhere else

The third rule is the one worth grepping for. Every context.Background() inside a request path is either failure two, or a comment waiting to be written explaining why it isn't.

Five things that break when you move from Jest to Vitest

MSakai — Sat, 15 Aug 2026 13:30:26 +0000

Vitest advertises a Jest-compatible API, and it delivers. describe, test, expect, toHaveBeenCalledWith — all identical. Which is why the five things that aren't compatible are so disorienting: the suite mostly runs, and then a handful of files fail for reasons the error messages don't explain.

1. Globals are opt-in

Jest injects describe and expect into the global scope. Vitest doesn't, by default.

// vitest.config.ts
export default defineConfig({
  test: { globals: true },
})

Plus, for types:

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

The alternative — importing explicitly — is the better long-term choice, but do it as a separate commit. Mixing "migrate the runner" with "touch every test file" makes the diff unreviewable.

import { describe, test, expect, vi } from 'vitest'

2. `moduleNameMapper` doesn't exist

Path aliases move out of the test config and into Vite's resolver, where they're shared with your build:

// jest.config.js
moduleNameMapper: { '^@/(.*)$': '<rootDir>/src/$1' }

// vitest.config.ts
import { fileURLToPath } from 'node:url'

export default defineConfig({
  resolve: {
    alias: { '@': fileURLToPath(new URL('./src', import.meta.url)) },
  },
})

This is a net win — one place instead of two — but it means your test aliases now affect your bundle. Check them.

3. `jest.mock` hoists differently than you remember

Both hoist. The difference is what happens to variables the factory closes over. In Vitest you need vi.hoisted:

const { mockFetch } = vi.hoisted(() => ({ mockFetch: vi.fn() }))
vi.mock('./api', () => ({ fetchUser: mockFetch }))

Jest's jest.mock tolerated a variable named with a mock prefix as a special case. Vitest has no such carve-out, so the mockFoo naming convention that used to be load-bearing in your Jest suite now does nothing.

4. `restoreMocks` behaves differently than `clearMocks`

Three settings, easily confused, and the Jest defaults don't carry over:

Option	Effect
`clearMocks`	Resets calls and instances between tests
`mockReset`	The above, plus resets the implementation to `undefined`
`restoreMocks`	The above, plus restores the original implementation for spies

If you relied on Jest's restoreMocks: true in jest.config.js, set it explicitly:

export default defineConfig({
  test: { restoreMocks: true },
})

Symptom when you forget: a spy created with vi.spyOn in one test is still installed in the next one, and a completely unrelated test starts asserting against a stub.

5. Environments are per-file, and `jsdom` is not bundled

Vitest ships no DOM implementation. Install one:

npm i -D jsdom

Then set it globally, or per file — which is the feature Jest never had:

// @vitest-environment jsdom

That comment at the top of a file overrides the config for that file alone. Mixing node-environment and jsdom tests in one run stops being a config negotiation.

What to do first

Run the suite before changing a single test file. The failures cluster: aliases first, then mocks, then environment. Fixing them in that order means each batch of failures has one cause, rather than three tangled together.

The parts that don't break — assertions, matchers, snapshots, coverage output — are genuinely the bulk of a suite. The migration is real, but it's an afternoon, not a rewrite.

Your Three.js scene is leaking, and removing the mesh didn't help

MSakai — Thu, 13 Aug 2026 14:22:03 +0000

The symptom is unmistakable once you've seen it: navigate between two views a dozen times and the tab climbs past a gigabyte, or the frame rate degrades and never recovers.

scene.remove(mesh)
mesh = null

Both lines run. Memory doesn't come back.

What `remove` does and doesn't do

scene.remove() detaches the object from the scene graph. That's all it does. JavaScript will happily collect the Mesh object itself.

But a Mesh is a thin wrapper. The actual data — vertex buffers, index buffers, texture uploads, compiled shader programs — lives in WebGL, on the GPU, allocated through the rendering context. The garbage collector has no visibility into that at all. Those resources are freed only when you explicitly ask.

What actually needs disposing

Three things, and each one is separate:

function disposeMesh(mesh) {
  mesh.geometry.dispose()

  const materials = Array.isArray(mesh.material) ? mesh.material : [mesh.material]
  for (const material of materials) {
    for (const key of Object.keys(material)) {
      const value = material[key]
      if (value && value.isTexture) value.dispose()
    }
    material.dispose()
  }
}

The texture loop matters more than it looks. A single MeshStandardMaterial can hold map, normalMap, roughnessMap, metalnessMap, aoMap, emissiveMap, displacementMap — seven separate uploads, none of which material.dispose() touches.

Doing it for a whole subtree

function disposeHierarchy(root) {
  root.traverse((obj) => {
    if (obj.isMesh || obj.isPoints || obj.isLine) disposeMesh(obj)
  })
  root.parent?.remove(root)
}

traverse visits the node and all descendants, so this handles a loaded glTF scene in one call.

The things that are easy to forget

Render targets. WebGLRenderTarget holds a framebuffer and at least one texture. Post-processing chains often hold several.

renderTarget.dispose()
composer.dispose()

Controls and listeners. OrbitControls attaches to the DOM element. Not disposing it keeps the whole scene alive through the listener closure — a plain JavaScript leak on top of the GPU one.

controls.dispose()

The renderer itself, when you're tearing down for good:

renderer.dispose()
renderer.forceContextLoss()

A browser will only give a page a limited number of WebGL contexts — commonly around 16. Create-and-abandon in a single-page app and you'll eventually get a blank canvas with Too many active WebGL contexts in the console, which is the same bug wearing a different hat.

Measure it, don't guess

The renderer exposes exactly what you need:

console.log(renderer.info.memory)    // { geometries: 42, textures: 17 }

Log this on every route change. In a healthy app the numbers return to baseline. If they only ever climb, you have your answer — and unlike a heap snapshot, this points directly at which resource type is leaking.

The framework wrapper

If you're on React Three Fiber, R3F disposes automatically when a component unmounts, which removes most of this problem. The exception is anything you constructed outside the render tree — a new THREE.TextureLoader().load(...) stored in a ref, a manually created render target — and those are exactly the cases where the automatic behaviour lulls you into not checking.

renderer.info.memory still tells the truth.

The takeaway

remove is about the scene graph. dispose is about the GPU. They are unrelated operations, and only one of them frees memory.

The pytest fixture that quietly leaks state between your tests

MSakai — Tue, 11 Aug 2026 14:19:53 +0000

The suite is green. You run it with -p no:randomly off, or add a test in the middle, and two unrelated tests turn red.

@pytest.fixture(scope="module")
def config():
    return {"retries": 3, "debug": False}

def test_debug_mode(config):
    config["debug"] = True
    assert some_feature(config) == "verbose"

def test_default_mode(config):
    assert some_feature(config) == "quiet"   # fails if it runs second

What's actually happening

scope="module" means the fixture body runs once per module, and every test in that module receives the same object. Not a copy. The dict test_debug_mode mutated is the dict test_default_mode receives.

This is invisible while your tests happen to run in a forgiving order, which is exactly what makes it expensive to debug later.

The rule that decides scope

Scope is about cost of setup, and it is only safe when the object is read-only or self-cleaning.

Scope	Use when
`function` (default)	Anything mutable. Start here.
`class` / `module`	Setup is expensive and the object is immutable or reset between tests
`session`	Genuinely global and expensive: a container, a test database, a browser

If you cannot say "nothing in this module mutates it", it belongs at function scope.

Three fixes, in order of preference

1. Drop the scope. The cheapest fix is usually the right one. Building a dict costs nothing.

@pytest.fixture
def config():
    return {"retries": 3, "debug": False}

2. Keep the expensive part shared, hand out a copy.

@pytest.fixture(scope="module")
def _base_config():
    return load_config_from_disk()      # the expensive bit, done once

@pytest.fixture
def config(_base_config):
    return copy.deepcopy(_base_config)  # each test gets its own

3. Make it immutable so the mutation fails loudly.

from types import MappingProxyType

@pytest.fixture(scope="module")
def config():
    return MappingProxyType({"retries": 3, "debug": False})

Now config["debug"] = True raises TypeError in the test that caused the problem, instead of failing a different test five minutes later.

Prove it before it bites you

Install pytest-randomly and let order-dependence surface in CI rather than in a Friday afternoon debugging session:

pip install pytest-randomly
pytest            # shuffles test order every run, prints the seed
pytest -p no:randomly   # reproduce the old behaviour when you need to

A suite that only passes in one specific order isn't a passing suite. It is a suite you haven't finished writing yet.

The takeaway

Widening a fixture's scope is a performance optimisation. Treat it like any other optimisation: only after you've measured, and only when you can prove nobody mutates the shared object.

Fake timers and await are fighting in your Vitest test

MSakai — Sun, 09 Aug 2026 13:50:39 +0000

You mock the clock, advance it, and assert. The assertion runs before the code under test has finished.

async function poll() {
  await new Promise((r) => setTimeout(r, 1000))
  return 'done'
}

test('resolves after a second', () => {
  vi.useFakeTimers()
  const p = poll()
  vi.advanceTimersByTime(1000)
  expect(p).resolves.toBe('done')  // never settles in time
})

What's actually happening

advanceTimersByTime is synchronous. It fires every timer callback whose deadline has passed and then returns immediately — in the same tick.

But poll doesn't finish when the timer fires. The timer resolves a promise, and the code after await is queued as a microtask. Microtasks only run when the current synchronous block yields. Your assertion is still inside that block.

So the ordering is:

advanceTimersByTime(1000) — timer callback runs, promise resolves
expect(...) — still in the same tick, continuation hasn't run
test ends
microtask would have run, but nobody is listening

The fix

Use the async variant. It advances the clock and drains the microtask queue between timers:

test('resolves after a second', async () => {
  vi.useFakeTimers()
  const p = poll()
  await vi.advanceTimersByTimeAsync(1000)
  await expect(p).resolves.toBe('done')
})

Every timer method has an async twin:

sync	async
`advanceTimersByTime`	`advanceTimersByTimeAsync`
`runAllTimers`	`runAllTimersAsync`
`runOnlyPendingTimers`	`runOnlyPendingTimersAsync`
`advanceTimersToNextTimer`	`advanceTimersToNextTimerAsync`

The async versions also pick up timers that get scheduled during the advance — a setTimeout registered inside a resolved promise, for example. The sync versions cannot see those, because the promise hasn't resolved yet when they run.

When you actually need the sync version

Almost never, if there's a promise anywhere in the chain. Reach for the sync methods only when the code under test is entirely callback-based with no promises involved:

const spy = vi.fn()
setInterval(spy, 100)
vi.advanceTimersByTime(350)
expect(spy).toHaveBeenCalledTimes(3)   // fine, no microtasks in play

Two more things that bite

Restore the clock. Leaving fake timers installed leaks into the next file when tests share a worker:

afterEach(() => { vi.useRealTimers() })

Watch out for infinite intervals. runAllTimersAsync on a setInterval that reschedules forever will throw after 10 000 iterations rather than hang. That error message is telling you to use advanceTimersByTimeAsync with a bound instead.

The rule

If there is an await anywhere between the timer and the assertion, use the Async variant.

That one substitution fixes the overwhelming majority of "my fake timer test just hangs" reports.

Your Go table test passes, but not for the reason you think

MSakai — Fri, 07 Aug 2026 14:13:33 +0000

Here is the updated article incorporating Swapnoneel's excellent suggestion to explicitly show the two distinct failure modes, followed by a drafted reply to the comment.

Updated Article

title: "Your Go table test passes, but not for the reason you think"

published: true
description: "t.Parallel inside a table test defers the subtest until the loop is over. Before Go 1.22 that quietly tested the last case N times, but the underlying scheduling trap remains."
tags: go, testing, concurrency, programming

This is the single most reproduced bug in Go test suites, and it is green the whole time it is wrong.

func TestValidate(t *testing.T) {
    cases := []struct {
        name string
        in   string
        want bool
    }{
        {"empty", "", false},
        {"valid", "abc", true},
        {"too long", strings.Repeat("x", 300), false},
    }

    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel()
            if got := Validate(tc.in); got != tc.want {
                t.Errorf("got %v want %v", got, tc.want)
            }
        })
    }
}

What `t.Parallel` actually does

It does not immediately start a goroutine. It pauses the subtest and returns control to the parent. The parent keeps looping. Only when the parent's function body finishes do the paused subtests resume and run together.

This scheduling rule creates two distinct traps. Go 1.22 fixed the first one, but the second one is baked into the test structure itself.

Failure 1: The Loop Capture Trap (Fixed in Go 1.22)

Because t.Parallel() defers execution, the for loop completes before any subtest actually runs.

In Go 1.21 and earlier, tc was a single variable reused across iterations. By the time the subtests resumed, the loop was over, and they all read the final value of tc:

--- PASS: TestValidate/empty      (actually ran "too long")
--- PASS: TestValidate/valid      (actually ran "too long")
--- PASS: TestValidate/too_long

Three passes. One case tested. The names in the output are correct — they were captured by t.Run before the pause — which is what makes it so convincing. (The cheapest way to confirm this is to deliberately break one case like {"valid", "abc", false}; if zero or three tests fail instead of exactly one, your loop is capturing incorrectly).

The Go 1.22 Fix:
As of Go 1.22, loop variables are per-iteration. Each tc is a distinct variable, so the capture is correct and the old tc := tc shadowing line is no longer needed.

(Note: The new semantics apply only when the module's go directive in go.mod says go 1.22 or later. Bumping your toolchain is not enough).

Failure 2: The Early Cleanup Trap (Still broken in 1.22+)

Per-iteration variables fixed the capture bug, but they did not change when parallel subtests run. Anything at the end of your parent test still executes before the subtests resume.

If we add a database or file closure to our test, it will fail (or panic), even in Go 1.22:

func TestWithDatabase(t *testing.T) {
    db := ConnectDB()

    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel()
            db.Query(tc.in) // PANIC! db is already closed.
        })
    }

    db.Close() // Runs BEFORE any subtest body!
    // (Using `defer db.Close()` at the top of the function does the exact same thing)
}

Because t.Parallel() means "resume me after my parent returns", the parent finishes the loop, calls db.Close(), returns, and then the subtests try to query the closed database.

The Fix:
The standard fix is to use t.Cleanup(), which registers a callback that strictly waits until all parallel children have finished:

func TestWithDatabase(t *testing.T) {
    db := ConnectDB()
    t.Cleanup(func() { db.Close() }) // Safe: waits for subtests

    for _, tc := range cases {
        // ...
    }
}

The takeaway

t.Parallel() means "resume me after my parent returns". Every surprise it causes follows from that one sentence.

satisfies replaced most of my type annotations, and all of my as

MSakai — Wed, 05 Aug 2026 13:31:21 +0000

You have a config object. You want two things at once:

TypeScript should check it against a type
TypeScript should remember the exact values you wrote

Before TS 4.9 you could have either one. Not both.

Annotating loses the detail

type Config = Record<string, string | number>

const config: Config = {
  host: 'localhost',
  port: 3000,
}

config.port.toFixed()  // Error: Property 'toFixed' does not exist on 'string | number'

The annotation checked the object, then widened every value to string | number. You knew port was a number. The compiler no longer does.

Omitting the annotation loses the check

const config = {
  host: 'localhost',
  prot: 3000,       // typo, nobody notices
}

config.port.toFixed()  // Error: Property 'port' does not exist

Now the types are precise but the typo went unchallenged until a call site failed, three files away.

`as` is worse than both

const config = {
  host: 'localhost',
  prot: 3000,
} as Config

This compiles. as is an assertion: you are telling the compiler to stop reasoning and take your word for it. The typo survives to runtime, and you have removed the one mechanism that would have caught it.

`satisfies` does both

const config = {
  host: 'localhost',
  port: 3000,
} satisfies Config

config.port.toFixed()  // number
config.host.toUpperCase()  // string

The expression is checked against Config, and the inferred type stays exactly what you wrote. Misspell port and you get an error at the object literal, where the mistake is.

Where it earns its keep

Route or event maps. Keys stay literal, so downstream code can be exhaustive:

const routes = {
  home: '/',
  profile: '/users/:id',
} satisfies Record<string, `/${string}`>

type RouteName = keyof typeof routes   // 'home' | 'profile'

With an annotation, RouteName would have collapsed to string.

Theme tokens. You want the shape validated and the keys autocompleted:

const theme = {
  primary: '#0af',
  danger: '#f33',
} satisfies Record<string, `#${string}`>

Discriminated unions in arrays. Each element is checked, and narrowing still works afterwards:

const handlers = [
  { kind: 'click', fn: (e: MouseEvent) => {} },
  { kind: 'key',   fn: (e: KeyboardEvent) => {} },
] satisfies Handler[]

When to keep the annotation

satisfies is not a replacement for annotations everywhere. Keep the annotation when you want the wider type — usually on a let, or on something that gets reassigned:

let state: 'idle' | 'loading' | 'done' = 'idle'
state = 'loading'   // needs the annotation to be legal

With satisfies here, state would be inferred as 'idle' and the reassignment would fail.

The rule

Annotate when you want the wider type. Use satisfies when you want the check without the widening. Use as when you have genuinely more information than the compiler — which is rarer than your codebase currently suggests.

Grep for as in your project. A good fraction of the hits are satisfies waiting to happen, and each one you convert is a check you get back.

Why your vi.mock in Vitest silently does nothing

MSakai — Mon, 03 Aug 2026 07:11:20 +0000

You wrote a mock. The test still hits the real module. Nothing in the error message points at why.

import { fetchUser } from './api'
import { vi, test, expect } from 'vitest'

const mockFetch = vi.fn()
vi.mock('./api', () => ({ fetchUser: mockFetch }))  // ReferenceError

What actually happens

vi.mock is hoisted to the top of the file by Vitest's transform, above every import. So by the time the factory runs, mockFetch does not exist yet.

Order at runtime:

vi.mock('./api', factory) — registered first
import { fetchUser } from './api' — resolved, factory invoked
const mockFetch = vi.fn() — too late

The fix

Use vi.hoisted so the mock value is created in the same hoisted phase:

const { mockFetch } = vi.hoisted(() => ({ mockFetch: vi.fn() }))

vi.mock('./api', () => ({ fetchUser: mockFetch }))

Or skip the shared variable entirely and reach for the mocked module inside the test:

import { fetchUser } from './api'

vi.mock('./api')

test('calls the api', async () => {
  vi.mocked(fetchUser).mockResolvedValue({ id: 1 })
  // ...
})

The rule worth memorising

Anything referenced inside a vi.mock factory must be created by vi.hoisted, or defined inside the factory itself.

That one line prevents most of the mocking bugs people file against Vitest.

Want the full picture?

I cover this end-to-end in my Udemy course: Vitest by Example: 50 Hands-on Drills for TypeScript Unit Testing

10h / Beginner to Intermediate

The link above includes a discount coupon, valid until 2026-08-31. After that it works as a regular course link.

DEV Community: MSakai

Test your FastAPI routes without touching the database

The intended mechanism

Where this pays off most: auth

Overriding per test, not per suite

What to still use a real database for

The distinction worth keeping

monkeypatch or mock.patch? One question decides it

The question

When you only need a value

When you need to inspect the call

The mistake both share

A practical hybrid

The summary

Checking your A/B test every morning makes it lie to you

Why looking changes the result

What it costs, concretely

Three ways out

The one thing that isn't negotiable

The uncomfortable implication

The context you passed is not the context that cancels

Failure one: the work dies with the request

Failure two: the cancellation never arrives

Making it visible

The convention that prevents both

Five things that break when you move from Jest to Vitest

1. Globals are opt-in

2. moduleNameMapper doesn't exist

3. jest.mock hoists differently than you remember

4. restoreMocks behaves differently than clearMocks

5. Environments are per-file, and jsdom is not bundled

What to do first

Your Three.js scene is leaking, and removing the mesh didn't help

What remove does and doesn't do

What actually needs disposing

Doing it for a whole subtree

The things that are easy to forget

Measure it, don't guess

The framework wrapper

The takeaway

The pytest fixture that quietly leaks state between your tests

What's actually happening

The rule that decides scope

Three fixes, in order of preference

Prove it before it bites you

The takeaway

Fake timers and await are fighting in your Vitest test

What's actually happening

The fix

When you actually need the sync version

Two more things that bite

The rule

Your Go table test passes, but not for the reason you think

Updated Article

title: "Your Go table test passes, but not for the reason you think"

What t.Parallel actually does

Failure 1: The Loop Capture Trap (Fixed in Go 1.22)

Failure 2: The Early Cleanup Trap (Still broken in 1.22+)

The takeaway

satisfies replaced most of my type annotations, and all of my as

Annotating loses the detail

Omitting the annotation loses the check

as is worse than both

satisfies does both

Where it earns its keep

When to keep the annotation

The rule

Why your vi.mock in Vitest silently does nothing

What actually happens

The fix

The rule worth memorising

Want the full picture?

2. `moduleNameMapper` doesn't exist

3. `jest.mock` hoists differently than you remember

4. `restoreMocks` behaves differently than `clearMocks`

5. Environments are per-file, and `jsdom` is not bundled

What `remove` does and doesn't do

What `t.Parallel` actually does

`as` is worse than both

`satisfies` does both