archvillainette
7e7108c48b
Adds the shared agent-skill core under `.agents/skills/` (grilling, grill-me, domain-modeling, codebase-design, code-review, diagnosing-bugs, tdd, research, implement, handoff), with `.claude` symlinked to `.agents` so every agent harness picks them up. Project-local skills are left untouched. The runtime `scheduled_tasks.lock` is deliberately not committed. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Reviewed-on: #20 Reviewed-by: xtul <mpiasecki720@protonmail.com> Co-authored-by: vickydotbat <vickydotbat@tutamail.com> Co-committed-by: vickydotbat <vickydotbat@tutamail.com>
1.4 KiB
1.4 KiB
When to Mock
Mock at system boundaries only:
- External APIs (payment, email, etc.)
- Databases (sometimes - prefer test DB)
- Time/randomness
- File system (sometimes)
Don't mock:
- Your own classes/modules
- Internal collaborators
- Anything you control
Designing for Mockability
At system boundaries, design interfaces that are easy to mock:
1. Use dependency injection
Pass external dependencies in rather than creating them internally:
// Easy to mock
function processPayment(order, paymentClient) {
return paymentClient.charge(order.total);
}
// Hard to mock
function processPayment(order) {
const client = new StripeClient(process.env.STRIPE_KEY);
return client.charge(order.total);
}
2. Prefer SDK-style interfaces over generic fetchers
Create specific functions for each external operation instead of one generic function with conditional logic:
// GOOD: Each function is independently mockable
const api = {
getUser: (id) => fetch(`/users/${id}`),
getOrders: (userId) => fetch(`/users/${userId}/orders`),
createOrder: (data) => fetch('/orders', { method: 'POST', body: data }),
};
// BAD: Mocking requires conditional logic inside the mock
const api = {
fetch: (endpoint, options) => fetch(endpoint, options),
};
The SDK approach means:
- Each mock returns one specific shape
- No conditional logic in test setup
- Easier to see which endpoints a test exercises
- Type safety per endpoint