987fdd16db
All checks were successful
ci/woodpecker/push/default Pipeline was successful
Make the admin's Claude Code agent skills available to the `emo` devvm user. Viktor asked to install Matt Pocock's skills for emo, starting with grill-me but covering the full set the admin already uses. The `npx skills` upstream has drifted off that set (diagnose -> diagnosing-bugs and write-a-skill -> writing-great-skills were renamed; caveman + zoom-out are no longer published), so reproducing it via npx is impossible and would also spray ~70 agent dirs into the user's home + add a GitHub-clone + unpinned-CLI dependency to the hourly root reconcile. Instead vendor a point-in-time snapshot of the 16 skills (scripts/workstation/claude-skills/) and copy them per-user, mirroring install_memory: install_skills() copies each skill into ~/.agents/skills/<name> (owned by the user) and symlinks ~/.claude/skills/<name> -> ../../.agents/skills/<name>. if-absent, additive, best-effort, scoped to the SKILL_USERS allowlist (emo). find-skills is from vercel-labs/skills (not Matt Pocock) but included since it is part of the admin's current set. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.6 KiB
1.6 KiB
Good and Bad Tests
Good Tests
Integration-style: Test through real interfaces, not mocks of internal parts.
// GOOD: Tests observable behavior
test("user can checkout with valid cart", async () => {
const cart = createCart();
cart.add(product);
const result = await checkout(cart, paymentMethod);
expect(result.status).toBe("confirmed");
});
Characteristics:
- Tests behavior users/callers care about
- Uses public API only
- Survives internal refactors
- Describes WHAT, not HOW
- One logical assertion per test
Bad Tests
Implementation-detail tests: Coupled to internal structure.
// BAD: Tests implementation details
test("checkout calls paymentService.process", async () => {
const mockPayment = jest.mock(paymentService);
await checkout(cart, payment);
expect(mockPayment.process).toHaveBeenCalledWith(cart.total);
});
Red flags:
- Mocking internal collaborators
- Testing private methods
- Asserting on call counts/order
- Test breaks when refactoring without behavior change
- Test name describes HOW not WHAT
- Verifying through external means instead of interface
// BAD: Bypasses interface to verify
test("createUser saves to database", async () => {
await createUser({ name: "Alice" });
const row = await db.query("SELECT * FROM users WHERE name = ?", ["Alice"]);
expect(row).toBeDefined();
});
// GOOD: Verifies through interface
test("createUser makes user retrievable", async () => {
const user = await createUser({ name: "Alice" });
const retrieved = await getUser(user.id);
expect(retrieved.name).toBe("Alice");
});