Testing — Vitest, Jest & Playwright

10. Practice Problems

1. Write 3 tests for a divide(a, b) function (positive, negative, b=0).
   ✨ Show Answer

   a1.js

   const divide = (a, b) => { if (b === 0) throw new Error("div0"); return a / b; };
   function test(name, fn) {
       try { fn(); console.log("✓", name); }
       catch (e) { console.log("✗", name, e.message); }
   }
   test("10/2", () => { if (divide(10, 2) !== 5) throw new Error("x"); });
   test("-6/3", () => { if (divide(-6, 3) !== -2) throw new Error("x"); });
   test("div0 throws", () => {
       try { divide(1, 0); throw new Error("didn't throw"); }
       catch (e) { if (e.message !== "div0") throw e; }
   });

   Run Copy

2. Test debounce with a fake timer (logic).
   ✨ Show Answer

   // Vitest fake timers
   import { vi } from "vitest";
   
   it("debounce fires only after silence", () => {
       vi.useFakeTimers();
       const fn = vi.fn();
       const d = debounce(fn, 100);
       d(); d(); d();
       vi.advanceTimersByTime(100);
       expect(fn).toHaveBeenCalledTimes(1);
   });

3. Why does aiming for 100% test coverage often backfire?
   ✨ Show Answer

   Answer: The last 5–10% comes from trivial getters and one-line passthroughs that catch nothing. You spend hours mocking the world to lift the number — and the resulting tests are brittle, slow, and produce false confidence. Aim for 70–85% with sharp tests on the logic that actually matters.

4. Build a runnable assertion that an array is sorted.
   ✨ Show Answer

   a4.js

   const isSorted = a => a.every((v, i) => i === 0 || a[i - 1] <= v);
   console.log(isSorted([1, 2, 2, 3]));
   console.log(isSorted([2, 1]));

   Run Copy

5. Compare unit test vs E2E in two sentences.
   ✨ Show Answer

   Answer: Unit tests check a single function in isolation — fast, deterministic, useful for refactor confidence. E2E tests drive a real browser through the actual UI — slow, more flaky, but they catch the integration bugs that unit tests cannot.

6. Sketch a Playwright test for a login flow.
   ✨ Show Answer

   test("login", async ({ page }) => {
       await page.goto("/login");
       await page.getByLabel("Email").fill("a@x.com");
       await page.getByLabel("Password").fill("pw");
       await page.getByRole("button", { name: "Sign in" }).click();
       await expect(page.getByText("Dashboard")).toBeVisible();
   });

7. Why is mocking the network usually better than hitting it in tests?
   ✨ Show Answer

   Answer: Real network is slow, flaky, and depends on services you don't control. A mock gives instant deterministic responses — the test runs in milliseconds and never fails because someone else's API is down. Reserve real-network tests for one or two end-to-end "smoke" runs.

8. In one paragraph, when should you write a test before the code?
   ✨ Show Answer

   Answer: Test-first works best for pure functions with clear inputs/outputs (parsers, validators, math), where writing the test forces you to nail the contract. For UI work or research code, writing tests after a working sketch is usually faster — premature tests against unstable APIs slow you down. Pragmatism beats dogma.