Loading...
Loading...
Use when writing, fixing, editing, or refactoring TypeScript tests, especially slow or flaky tests, skipped or focused tests, happy-path-only coverage, missing boundaries, brittle fixtures, coverage gaps, or multi-concept tests.
npx skill4agent add gosukiwi/clean-code-react clean-typescript-tests// Bad - only tests happy path
test("divide", () => {
expect(divide(10, 2)).toBe(5);
});
// Good - tests edge cases too
test("divide normal", () => {
expect(divide(10, 2)).toBe(5);
});
test("divide by zero", () => {
expect(() => divide(10, 0)).toThrow(RangeError);
});
test("divide negative", () => {
expect(divide(-10, 2)).toBe(-5);
});# Run with coverage
vitest run --coverage
# Aim for meaningful coverage, not 100%// Worth having - documents expected behavior
test("user default role", () => {
const user = new User("Alice");
expect(user.role).toBe("member");
});test.skip// Bad - hiding a problem
test.skip("async operation", () => {
// flaky, fix later
});
// Good - either fix it or document why it's skipped
test.skip("cache invalidation - requires Redis (see CONTRIBUTING.md)", () => {
});test("pagination boundaries", () => {
const items = Array.from({ length: 100 }, (_, i) => i);
// First page
expect(paginate(items, 1, 10)).toEqual(items.slice(0, 10));
// Last page
expect(paginate(items, 10, 10)).toEqual(items.slice(90, 100));
// Beyond last page
expect(paginate(items, 11, 10)).toEqual([]);
// Page zero (invalid)
expect(() => paginate(items, 0, 10)).toThrow(RangeError);
// Empty list
expect(paginate([], 1, 10)).toEqual([]);
});// Found bug: off-by-one in date calculation
// Now test ALL date boundaries
test("month boundaries", () => {
expect(lastDayOfMonth(2024, 1)).toBe(31); // January
expect(lastDayOfMonth(2024, 2)).toBe(29); // Leap year February
expect(lastDayOfMonth(2023, 2)).toBe(28); // Non-leap February
expect(lastDayOfMonth(2024, 4)).toBe(30); // 30-day month
expect(lastDayOfMonth(2024, 12)).toBe(31); // December
});// If all async tests fail intermittently,
// the problem isn't the tests - it's the async handling// If you can't easily test a function, it probably does too much
// Refactor for testability// Bad - hits real database
test("user creation", async () => {
const db = await connectToDatabase(); // Slow!
const user = await db.createUser("Alice");
expect(user.name).toBe("Alice");
});
// Good - uses mock or in-memory
test("user creation", async () => {
const db = new InMemoryDatabase();
const user = await db.createUser("Alice");
expect(user.name).toBe("Alice");
});as// Bad - noisy fixture hides the behavior under test
const order: Order = {
id: "order-1",
status: "paid",
customerId: "customer-1",
lineItems: [],
discounts: [],
createdAt: new Date("2026-01-01"),
};
// Good - default valid object, test overrides the relevant fact
const order = buildOrder({ status: "paid" });// Bad - testing multiple things
test("user", () => {
const user = new User("Alice", "alice@example.com");
expect(user.name).toBe("Alice");
expect(user.email).toBe("alice@example.com");
expect(user.isValid()).toBe(true);
user.activate();
expect(user.isActive).toBe(true);
});
// Good - one concept each
test("user stores name", () => {
const user = new User("Alice", "alice@example.com");
expect(user.name).toBe("Alice");
});
test("user stores email", () => {
const user = new User("Alice", "alice@example.com");
expect(user.email).toBe("alice@example.com");
});
test("new user is valid", () => {
const user = new User("Alice", "alice@example.com");
expect(user.isValid()).toBe(true);
});
test("user can be activated", () => {
const user = new User("Alice", "alice@example.com");
user.activate();
expect(user.isActive).toBe(true);
});