yukart/tool-mock
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Record self-mocking design: services mock themselves, no separate stubs

Browse Source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013kj58Jugkic783b8ZrtTVZ
This commit is contained in:
Mikkeli Matlock
2026-09-04 07:59:27 +09:00
parent 32d5df87ab
commit 358662de1b
1 changed files with 8 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/GUIDELINES.md
+8 -6
View File
@@ -9,12 +9,14 @@ type: default
- A fixture that invents its own topic or shape is worse than no fixture: it defers - A fixture that invents its own topic or shape is worse than no fixture: it defers
the integration work instead of removing it. the integration work instead of removing it.
## 2. Never stub our own services ## 2. Do not reimplement our own services
- Stub the **car** and the **hardware**. Never stub `svc-gw`, `svc-nav` or anything - Stub the **car** and the **hardware**. Never write a *separate* implementation of
else we wrote. `svc-gw`, `svc-nav` or anything else we wrote — a second implementation of our own
- A stub of our own service is a second implementation of our own contract, and it contract will drift from the first.
will drift from the first. Run the real service against fake inputs instead — - A service mocking **itself**, behind its own input interface, is the right shape:
none of our services touch hardware, so they all run on x86 unmodified. one codebase, one contract implementation, a swappable data source. That belongs
in the service's own repo, not here.
- None of our services touch hardware, so they all run on x86 unmodified either way.
## 3. Prefer upstream tools, wrap rather than rewrite ## 3. Prefer upstream tools, wrap rather than rewrite
- `vcan`, `canplayer` and ICSim already solve the CAN problem. This repo holds the - `vcan`, `canplayer` and ICSim already solve the CAN problem. This repo holds the