Files
skills/common/engineering/tdd/mocking.md
T
gitadmin 68f9b4691e feat(skills): add engineering skill definitions under common/engineering/ all from @mattpocock
Add 10 skill definitions covering codebase design, domain modeling,
test-driven development, triage, and development workflows:

- codebase-design: vocabulary and patterns for designing deep modules
- domain-modeling: build and sharpen project domain models
- grill-with-docs: interview-based design refinement with documentation
- improve-codebase-architecture: scan and report on deepening opportunities
- resolving-merge-conflicts: structured approach to merge/rebase conflicts
- setup-skills: per-repo configuration for engineering skills
- tdd: test-driven development workflow with vertical slices
- to-issues: break plans into tracer-bullet vertical slice issues
- to-prd: synthesize conversations into PRDs
- triage: state machine for issue/PR triage roles

Includes supporting files for ADR formats, issue tracker integrations
(GitHub, GitLab, Gitea), triage labels, and agent brief templates.
2026-06-25 12:01:55 -04:00

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