skills/post-dev-test/SKILL.md
Post-development test completion. Use when: checking test coverage after feature-dev, writing missing integration/e2e tests. Not for: unit test generation (use codex-test-gen), test review (use test-review). Output: test files + coverage report.
npx skillsauth add sd0xdev/sd0x-dev-flow post-dev-testInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Even if test coverage looks complete, tests must be executed whenever there are code changes.
| Scenario | Action | | ---------------------------- | ------------------------------------ | | Code changes exist | Must execute related integration/e2e | | Tests exist and are complete | Still execute to confirm no regression | | Tests missing or insufficient| Write then execute | | Pure doc/comment changes | Can skip |
Reason: Test coverage does not equal tests passing. Existing tests may fail due to code changes.
/codex-test-gen)/codex-test-review)/feature-dev flow first)┌─────────────────────────────────────────────────────────────────┐
│ Phase 1: Analyze Context │
├─────────────────────────────────────────────────────────────────┤
│ 1. From conversation history: what feature was developed? │
│ 2. Identify involved Service / Provider / Controller │
│ 3. List core flows and API endpoints │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ Phase 2: Check Existing Test Coverage │
├─────────────────────────────────────────────────────────────────┤
│ 1. Search test/integration/ for related tests │
│ 2. Search test/e2e/ for related tests │
│ 3. Assess coverage gaps │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ Phase 3: Determine Test Strategy │
├─────────────────────────────────────────────────────────────────┤
│ ┌──────────────┬────────────────────────────────────────────┐ │
│ │ Change Type │ Test Requirement │ │
│ ├──────────────┼────────────────────────────────────────────┤ │
│ │ New API │ Integration test (Controller + Service) │ │
│ │ New Service │ Integration test (Service layer) │ │
│ │ Cross-svc │ E2E test (complete flow) │ │
│ │ DB operation │ Integration test (actual DB) │ │
│ │ External API │ Integration test (mock external) │ │
│ └──────────────┴────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ Phase 4: Write Tests │
├─────────────────────────────────────────────────────────────────┤
│ 1. Reference existing test patterns │
│ 2. Use {FRAMEWORK_MOCK_LIB} createApp / createRequester │
│ 3. Follow TEST_ENV environment variable conventions │
│ 4. Write to corresponding directory │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ Phase 5: Execute Verification │
├─────────────────────────────────────────────────────────────────┤
│ 1. Execute newly added tests │
│ 2. Confirm passing │
│ 3. Report results │
└─────────────────────────────────────────────────────────────────┘
| Type | Directory | Naming | Env Variable |
| ----------- | ------------------- | -------------------------------------- | ---------------------- |
| Integration | test/integration/ | *.integration.test.ts or *.test.ts | TEST_ENV=integration |
| E2E | test/e2e/ | *.e2e.test.ts or *.test.ts | TEST_ENV=e2e |
import { Application, Framework } from '{FRAMEWORK_WEB}';
import { close, createApp } from '{FRAMEWORK_MOCK_LIB}';
import { ITestRequester, createRequester } from '../../createRequester';
import { TestEnvironment, onlyIf } from '../../helper/test-env';
const describeIntegration = onlyIf([
TestEnvironment.INTEGRATION,
TestEnvironment.E2E,
]);
describeIntegration('Feature Integration Tests', () => {
let app: Application;
let request: ITestRequester;
beforeAll(async () => {
app = await createApp<Framework>();
request = await createRequester(app);
});
afterAll(async () => {
await close(app);
});
describe('Scenario: ...', () => {
it('should ...', async () => {
// Arrange
// Act
// Assert
});
});
});
# Execute single integration test
TEST_ENV=integration yarn jest test/integration/path/to/test.ts
# Execute single e2e test
TEST_ENV=e2e yarn jest test/e2e/path/to/test.ts
Input: (User Authentication feature developed in conversation)
Phase 1: Identify ActiveAssetsWeeklyService, ActiveAssetsCacheService involved
Phase 2: Search test/e2e/auth/ -> found missing login test
Phase 3: Decide to write E2E test (cross-service flow)
Phase 4: Write active-assets-weekly.e2e.test.ts
Phase 5: Execute test and verify passing
Input: (New API endpoint developed in conversation)
Phase 1: Identify Controller + Service
Phase 2: Search test/integration/controller/ -> no corresponding test
Phase 3: Decide to write Integration test
Phase 4: Write new-feature.integration.test.ts
Phase 5: Execute test and verify passing
references/test-patterns.md - Existing test pattern referencedocumentation
Rewrite the previous reply in Traditional Chinese
development
Monitor GitHub Actions CI runs until completion. Use when: watching CI after push, checking build status, monitoring PR checks, waiting for CI completion, user says 'watch CI', 'check CI', 'CI status', 'monitor build', or /watch-ci. Not for: pushing code (use push-ci), creating PRs (use create-pr). Output: per-run verdict (pass/fail/timeout).
development
Verification loop — lint -> typecheck -> unit -> integration -> e2e
development
Research current code state then update corresponding docs, ensuring docs stay in sync with code.