Challenge 3: Build a Test Data Builder — Possible Solution
====================================================================

// user-fixtures.ts
interface User {
  id: string;
  name: string;
  email: string;
  role: "admin" | "member";
  active: boolean;
}

function buildUser(overrides: Partial<User> = {}): User {
  return {
    id: "user-1",
    name: "Jane Doe",
    email: "jane@example.com",
    role: "member",
    active: true,
    ...overrides,
  };
}

export { buildUser, User };

// user-fixtures.test.ts
import { buildUser } from "./user-fixtures";

describe("buildUser", () => {
  it("returns sensible defaults when no overrides are given", () => {
    const user = buildUser();
    expect(user.role).toBe("member");
    expect(user.active).toBe(true);
  });

  it("overrides only the role field for an admin test case", () => {
    const admin = buildUser({ role: "admin" });
    expect(admin.role).toBe("admin");
    expect(admin.name).toBe("Jane Doe"); // unchanged default
  });

  it("overrides only the active field for a deactivated user test case", () => {
    const deactivatedUser = buildUser({ active: false });
    expect(deactivatedUser.active).toBe(false);
    expect(deactivatedUser.email).toBe("jane@example.com"); // unchanged default
  });
});

WHY THIS WORKS
--------------
- Partial<User> makes every field on the overrides object optional, so a
  caller can pass just { role: "admin" } instead of specifying an entire
  User every time — the mapped type from Course 2 doing real work here.
- The spread operator (...overrides) applies after the defaults, so any
  field present in overrides wins; anything omitted falls back to the
  built-in default.
- Because buildUser's return type is User, TypeScript still catches typos
  or invalid values (e.g. role: "administrator") at the call site, even
  though the overrides themselves are optional.