如何通过服务端钩子推行TDD的红/绿/重构文化

Great question—coming off a legacy mess with near-zero test coverage and brittle, tightly coupled code, I totally get why you want to lock in good habits early with your new project. Server-side hooks are perfect for this, but they work best as guardrails, not handcuffs. Let’s break down how to use them to nurture the red/green/refactor cycle without driving your team crazy:

1. Start with the Green Phase—Make Tested Code the Only Code That Hits Main #

The biggest risk from your legacy project is untested code slipping in, so this is non-negotiable. Set up a pre-receive hook on your repo that enforces these basics:

• Require test coverage for new/modified code: Use tools like jest --coverage (JS/TS), coverage.py (Python), or simplecov (Ruby) in the hook. Start with a high threshold for new code (90% is a good baseline) and reject pushes where production code changes don’t have corresponding test coverage.
• Block pushes with failing tests: Run your full test suite (or a targeted subset for modified files) in the hook. If any test fails, the push gets rejected. This stops the "I’ll fix the test later" mindset that killed your legacy codebase.
• Enforce test file conventions: Make sure every production file (e.g., src/user-service.js) has a matching test file (e.g., tests/user-service.test.js). The hook can check that any new/modified production files have their test counterparts—no more "I forgot to add the test" excuses.

2. Nurture the Red Phase—Guide, Don’t Block #

The red phase (writing a failing test before writing code) is the heart of TDD, but it’s a local workflow—you can’t enforce it directly with hooks. Instead, use hooks to encourage transparency:

• Tag commit messages for workflow visibility: Add a pre-commit hook (enforced via server-side if needed) that requires commit messages to include tags like [RED] (for commits with failing tests) or [GREEN] (for commits that fix those tests). This makes the team’s TDD process visible—you can even set up a bot to flag [RED] commits in PRs so teammates can review the test logic early.
• Allow "red" commits only in feature branches: Configure your server-side hook to reject [RED] commits pushed to main/trunk, but let them live in feature branches. This lets teams work through the red phase without blocking their flow, but ensures only green, tested code makes it to the main codebase.

3. Protect the Refactor Phase—Prevent Regression #

Refactoring is about cleaning up code without breaking behavior—hooks can make sure refactors don’t turn into hidden bugs:

• Block refactor commits that drop coverage: If a commit is tagged [REFACTOR], the hook should check that test coverage hasn’t decreased. This ensures refactors don’t accidentally remove test coverage or skip edge cases.
• Require refactors to pass all tests: Even if you’re just renaming variables or cleaning up indentation, the hook must run the full test suite. This stops the "it’s just a small change" mindset that broke your legacy code.

4. Keep Hooks Flexible—Avoid Workarounds #

If your hooks are too strict, your team will find ways around them (like commenting out tests or pushing half-finished code). Build in exceptions for emergencies, but keep them accountable:

• Add a bypass flag: Let developers push with a --bypass-tdd-hook flag for critical fixes, but log every bypass and require a follow-up PR with tests within 24 hours.
• Gradual rollout: Start with a warning period—instead of rejecting pushes immediately, send a Slack alert to the team and code owner, then enforce the rules after 2-3 weeks. This gives everyone time to adjust to TDD workflows without feeling blindsided.

5. Pair Hooks with Cultural Reinforcement #

Hooks alone won’t fix bad habits—you need to support your team:

• Run TDD workshops: Walk through real examples of red/green/refactor, and tie it back to the pain points from the legacy project (e.g., "This is how we avoid the 'one tiny change breaks everything' problem we had before").
• Celebrate good practices: Highlight PRs that nail the TDD cycle in team meetings, or give a "TDD Champion" shoutout each week. Positive reinforcement works way better than strict rules.
• Iterate on hooks: Every sprint, review hook rejects and bypasses to find pain points. Maybe the test suite is too slow, or the coverage threshold is unrealistic. Adjust based on team feedback—this is your process, not a rigid rulebook.

At the end of the day, the goal isn’t to police your team—it’s to build a codebase that’s maintainable, just like you wish the legacy project was. Start small, listen to your team, and adjust as you go.

内容的提问来源于stack exchange，提问作者toriningen