Help us improve
Share bugs, ideas, or general feedback.
From backend-chapter
The goal is **deployment confidence**: the ability to merge and deploy without manually verifying that nothing broke.
npx claudepluginhub suitsupply/bec-marketplace-plugins --plugin backend-chapterHow this skill is triggered — by the user, by Claude, or both
Slash command
/backend-chapter:analyze-test-suiteThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The goal is **deployment confidence**: the ability to merge and deploy without manually verifying that nothing broke.
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
The goal is deployment confidence: the ability to merge and deploy without manually verifying that nothing broke.
Two readers:
Produce two ordered blocks:
For the reporter — suite health verdict:
Core question: if a change introduced a regression in this codebase today, would the test suite catch it — and would you trust the result?
Three axes, following a test's life — enable the code, construct the test, operate the suite. Flag where any falls short:
Enable (code under test) — can a test get at the behavior to check it, or does the code's shape block it — logic tangled with I/O, dependencies hard-wired instead of injected, one method doing too much to exercise in isolation? When this fails it is the root cause: the tests can't be good because the code won't let them.
Construct (test code) — once testable, is the test built to prove real behavior? Its three phases each fail independently:
Operate (pipeline & runtime) — once built, does the suite actually govern shipping? It must run at the right gate (unit and integration on every commit; e2e before the staging slot swap) and be trusted enough that a red stops the merge and a green clears it. Trust dies to three things: non-determinism, slowness, and dead tests. Evaluate by what the team does with the suite, not just whether the tests exist.
Verdict — use one of three:
Healthy — suite gives deployment confidence; no structural action neededNeeds attention: <one sentence> — gaps in coverage but infrastructure is soundRecommend rework story: <one sentence root cause> — describe what the story should address; do not create itNever fold suite rework into the current ticket's scope. The current ticket gets tests written within the existing setup, or the minimum new infrastructure its own tests require. Structural improvement is always a separate story.
For the implementing agent — concrete test plan. Specific enough the next agent writes the agreed tests, not a near-miss: skip the scenarios it will trivially discover, name the ones where a wrong guess diverges from the intended coverage.
Unit tests — per entry: Module.method → the edge case and why the integration layer can't cover it economically.
Integration/Component tests — the core of the plan. Per scenario:
State testcontainer images and factory setup once upfront if not already present in the suite.
E2E tests — per entry: the cross-service journey and why the integration layer would miss the regression. Default: none.
When the existing suite is broken, still produce recommendations showing what tests should look like — the rework story needs a concrete target.
**Assumption:** for the reporter to validate.The default approach is the testing diamond: few unit tests, many integration/component tests, few e2e tests. The middle layer earns deployment confidence because it tests real behavior through the real interface against real dependencies — no mocked databases, brokers, or external services.
NUnit + Moq — applies to all interface types.
Integration Tests — web application factory + Testcontainers. State container images and factory setup once upfront if not already present in the suite.
E2E Tests — NUnit + HttpClient against the staging slot. Run with dotnet test --logger trx for pipeline-integrated results. Cross-service journeys only
Integration Tests — Testcontainers for the message broker (Azure Service Bus emulator). Publish a message to the real broker; await observable side effects (DB state, downstream events emitted) via polling with timeout.
Keep entry point thin; inject dependencies (console, file system, services) so command handlers can be tested without the binary.
Integration Tests — invoke the entry point in-process (direct Main call) with Testcontainers for infrastructure dependencies; assert on exit code, stdout/stderr, and observable side effects.
E2E Tests — out-of-process via ProcessStartInfo against the compiled binary.
Component Tests — if the library performs no I/O, component tests are the primary layer (not the exception): call the public API directly with real internals, no mocks.
Integration Tests — if the library wraps infrastructure (database, cache, external API), Testcontainers; assert on observable side effects — same pattern as HTTP API, without the web application factory.
Vitest + vi.mock() — pure utility functions and hooks with logic too complex to reach economically through component rendering.
Vitest + React Testing Library against jsdom — the primary layer. Render the component, interact via userEvent, assert on the DOM. Wrap with renderWithProviders() for QueryClient and Router dependencies; use waitFor() for async assertions. Test files colocated in __tests__ next to the component.
Playwright — full browser against the deployed application; cross-page journeys and critical user flows only. Few, default none.