Having a regular checking routine beats digging through the console after a bug shows up. Don't write every test the same way — use unit tests for functions, component tests for interactive UI, and browser tests for the user journeys that really matter.
The key idea
TypeScript catches a lot of data-shape errors before anything even runs. ESLint checks code quality patterns, and unit tests quickly verify logic like a validation helper. End-to-end tests get closest to a real browser, checking actual flows like login, creating a note, or the deploy page. Rather than unit-testing a Server Component directly, it's more practical to test its data functions separately and check the async UI flow with E2E.
Let's try it together
import { describe, expect, it } from "vitest";
import { validateTitle } from "./validate-title";
describe("validateTitle", () => {
it("စာတိုလွန်းရင် error ပြန်သည်", () => {
expect(validateTitle("Hi")).toEqual({ ok: false });
});
it("သင့်တော်သော title ကိုလက်ခံသည်", () => {
expect(validateTitle("Next.js Notes")).toEqual({ ok: true });
});
});How the code works
The test checks that a too-short title gets rejected and that a proper title gets accepted. When writing a bug report, noting the expected result, actual result, steps, and environment makes it much easier to reproduce later.
Both validation rules pass their tests, so future regressions get caught.5-Minute Try-It
Write one success-case test and one empty-title error-case test for the note create flow.
Next.js — Testing — Next.js