/nw-test-organization-conventions
Test directory structure patterns by architecture style, language conventions, naming rules, and fixture placement. Decision tree for selecting test organization strategy.
Claude Code
$ npx -y skills add nWave-ai/nWave --skill nw-test-organization-conventions --agent claude-code
Codex
$ npx skills add nWave-ai/nWave --skill nw-test-organization-conventions -a codex -y
Cursor
$ npx skills add nWave-ai/nWave --skill nw-test-organization-conventions -a cursor -y
Gemini CLI
$ npx skills add nWave-ai/nWave --skill nw-test-organization-conventions -a gemini-cli -y
GitHub Copilot
$ npx skills add nWave-ai/nWave --skill nw-test-organization-conventions -a github-copilot -y
OpenCode
$ npx skills add nWave-ai/nWave --skill nw-test-organization-conventions -a opencode -y
Windsurf
$ npx skills add nWave-ai/nWave --skill nw-test-organization-conventions -a windsurf -y
SKILL.md
nw-test-organization-conventions.SKILL.mdname: nw-test-organization-conventions
description: Test directory structure patterns by architecture style, language conventions, naming rules, and fixture placement. Decision tree for selecting test organization strategy.
user-invocable: false
disable-model-invocation: true
Test Organization Conventions
Core Principle
Test directory structure encodes architectural boundaries. If a developer cannot infer the architecture from the test tree alone, the organization is wrong.
Architecture-to-Organization Decision Tree
What is the project's architectural style?
|
+-- Hexagonal / Clean Architecture
| --> Test-type-first: tests/{unit,integration,acceptance,e2e}/
| --> Domain concepts nested within each type
| --> Port contract tests in tests/integration/
|
+-- Vertical Slice
| --> Co-located: features/{slice}/tests/
| --> Cross-slice tests in top-level tests/cross_feature/
|
+-- Modular Monolith
| --> Module-first: tests/modules/{module}/{unit,integration}/
| --> Architecture tests per module (dependency rule enforcement)
| --> Inter-module tests in tests/inter_module/
|
+-- Microservices
| --> Per-service test tree: {service}/tests/{unit,integration,component,contract}/
| --> Contract tests: consumer writes in own repo, provider verifies in own repo
| --> Cross-service E2E in separate project: e2e-tests/
|
+-- Event-Driven
| --> Test-type-first with event-specific categories
| --> Unique: schema contract tests, idempotency tests, saga compensation tests
|
+-- CQRS
| --> Command/Query split within each test type
| --> Unique: projection tests (rebuild + idempotency)
|
+-- Layered (N-Tier)
| --> Mirror source: tests mirror src layer hierarchy
| --> Integration tests verify layer boundary contracts
|
+-- DDD (Tactical)
| --> Bounded-context-first: tests/{context}/domain/aggregates/
| --> Cross-context contract tests in tests/bounded_context_integration/Comparative Summary
| Architecture | Primary Axis | Secondary Axis | Unique Test Types | Co-located? | |-------------|-------------|----------------|-------------------|-------------| | Hexagonal | Test type | Domain concept | Port contract | No | | Clean | Test type | Architecture ring | Gateway | No | | Layered | Mirror source | Test type | Layer boundary | No (Java: yes) | | Vertical Slice | Feature | Test type | Cross-slice | Yes | | Modular Monolith | Module | Test type | Architecture, inter-module | No | | Microservices | Per-service | Test type | Contract (Pact) | No | | Event-Driven | Test type | Event flow role | Schema, idempotency, saga | No | | CQRS | Command/Query | Test type | Projection | No | | DDD | Bounded context | Building block | Aggregate, cross-context | No |
Mirror vs. Feature vs. Hybrid
| Strategy | Best For | Strengths | Weaknesses | |----------|----------|-----------|------------| | Mirror source | Layered, Clean, Hexagonal | Predictable paths, IDE navigation, package-private access (Java) | Feature changes touch multiple dirs | | Feature co-located | Vertical Slice, React | All feature code in one place, team ownership | Cross-feature tests homeless, hard to run by tier | | Hybrid (recommended) | Most projects | Type-first for CI stages, feature-nested within | Slightly deeper nesting |
Hybrid pattern (type-first, then feature within):
tests/
unit/
features/
order/test_create_order.py
payment/test_process_payment.py
integration/
features/
order/test_order_repository.py
e2e/
test_checkout_flow.pyLanguage-Specific Conventions
The table is illustrative, not a closed discovery allowlist. Follow actual manifest/build/test targets under `nw-test-design-mandates`, including Dune `test`/`tests`/alias stanzas, `.ml` and relevant `.mli`/opam dependencies in an OCaml project. Incumbent native layouts/helpers win; no `.py`, Gherkin, `tests/common` or compulsory adapter registration is inferred from this table.
| Language | File Convention | Discovery Rule | Co-located? | |----------|---------------|----------------|-------------| | Python (pytest) | `test_*.py` or `*_test.py` | Prefix/suffix match | Separate `tests/` (recommended) or inlined | | TypeScript/JS (Jest) | `*.test.ts`, `*.spec.ts`, `__tests__/*.ts` | testMatch pattern | Either | | Java (JUnit/Maven) | `*Test.java` in mirrored package | `src/test/java` mirrors `src/main/java` | Mirrored packages | | Go | `*_test.go` in same directory | Language-enforced co-location | Always co-located | | C# (xUnit/NUnit) | `*Tests.cs` in parallel project | Separate test project | Separate project | | Rust | `#[cfg(test)] mod tests` inline + `tests/` | Inline for unit, `tests/` for integration | Unit: inline, Integration: separate |
Python conftest.py Placement
Place `conftest.py` at the lowest directory where fixtures apply. Pytest discovers from outermost to innermost, enabling hierarchical fixture scoping:
tests/
conftest.py # Session fixtures: DB engine, app instance
unit/
conftest.py # Unit-specific: auto-mock markers
integration/
conftest.py # Integration: real DB fixtures
acceptance/
conftest.py # Acceptance: feature file pathsBDD Feature Files
tests/
features/ # Gherkin .feature files by domain
order/
place_order.feature
payment/
process_payment.feature
step_defs/ # Step implementations by domain concept
conftest.py
order_steps.py
payment_steps.pyOrganize step definitions by domain concept, not by feature file. Shared steps across features prevent duplication.
Hexagonal Architecture Test Tiers
| Tier | Location | Tests | Adapters | |------|----------|-------|----------| | Unit | tests/unit/ | Domain model, value objects, service layer | None (pure) or mock driven ports | | Integration | tests/integration/ | Individual adapters against real infra | Real infrastructure | | Acceptance | t
Read more
name: nw-test-organization-conventions description: Test directory structure patterns by architecture style, language conventions, naming rules, and fixture placement. Decision tree for selecting test organization strategy. user-invocable: false disable-model-invocation: true
Test Organization Conventions
Core Principle
Test directory structure encodes architectural boundaries. If a developer cannot infer the architecture from the test tree alone, the organization is wrong.
Architecture-to-Organization Decision Tree
What is the project's architectural style?
|
+-- Hexagonal / Clean Architecture
| --> Test-type-first: tests/{unit,integration,acceptance,e2e}/
| --> Domain concepts nested within each type
| --> Port contract tests in tests/integration/
|
+-- Vertical Slice
| --> Co-located: features/{slice}/tests/
| --> Cross-slice tests in top-level tests/cross_feature/
|
+-- Modular Monolith
| --> Module-first: tests/modules/{module}/{unit,integration}/
| --> Architecture tests per module (dependency rule enforcement)
| --> Inter-module tests in tests/inter_module/
|
+-- Microservices
| --> Per-service test tree: {service}/tests/{unit,integration,component,contract}/
| --> Contract tests: consumer writes in own repo, provider verifies in own repo
| --> Cross-service E2E in separate project: e2e-tests/
|
+-- Event-Driven
| --> Test-type-first with event-specific categories
| --> Unique: schema contract tests, idempotency tests, saga compensation tests
|
+-- CQRS
| --> Command/Query split within each test type
| --> Unique: projection tests (rebuild + idempotency)
|
+-- Layered (N-Tier)
| --> Mirror source: tests mirror src layer hierarchy
| --> Integration tests verify layer boundary contracts
|
+-- DDD (Tactical)
| --> Bounded-context-first: tests/{context}/domain/aggregates/
| --> Cross-context contract tests in tests/bounded_context_integration/Comparative Summary
| Architecture | Primary Axis | Secondary Axis | Unique Test Types | Co-located? | |-------------|-------------|----------------|-------------------|-------------| | Hexagonal | Test type | Domain concept | Port contract | No | | Clean | Test type | Architecture ring | Gateway | No | | Layered | Mirror source | Test type | Layer boundary | No (Java: yes) | | Vertical Slice | Feature | Test type | Cross-slice | Yes | | Modular Monolith | Module | Test type | Architecture, inter-module | No | | Microservices | Per-service | Test type | Contract (Pact) | No | | Event-Driven | Test type | Event flow role | Schema, idempotency, saga | No | | CQRS | Command/Query | Test type | Projection | No | | DDD | Bounded context | Building block | Aggregate, cross-context | No |
Mirror vs. Feature vs. Hybrid
| Strategy | Best For | Strengths | Weaknesses | |----------|----------|-----------|------------| | Mirror source | Layered, Clean, Hexagonal | Predictable paths, IDE navigation, package-private access (Java) | Feature changes touch multiple dirs | | Feature co-located | Vertical Slice, React | All feature code in one place, team ownership | Cross-feature tests homeless, hard to run by tier | | Hybrid (recommended) | Most projects | Type-first for CI stages, feature-nested within | Slightly deeper nesting |
Hybrid pattern (type-first, then feature within):
tests/
unit/
features/
order/test_create_order.py
payment/test_process_payment.py
integration/
features/
order/test_order_repository.py
e2e/
test_checkout_flow.pyLanguage-Specific Conventions
The table is illustrative, not a closed discovery allowlist. Follow actual manifest/build/test targets under `nw-test-design-mandates`, including Dune `test`/`tests`/alias stanzas, `.ml` and relevant `.mli`/opam dependencies in an OCaml project. Incumbent native layouts/helpers win; no `.py`, Gherkin, `tests/common` or compulsory adapter registration is inferred from this table.
| Language | File Convention | Discovery Rule | Co-located? | |----------|---------------|----------------|-------------| | Python (pytest) | `test_*.py` or `*_test.py` | Prefix/suffix match | Separate `tests/` (recommended) or inlined | | TypeScript/JS (Jest) | `*.test.ts`, `*.spec.ts`, `__tests__/*.ts` | testMatch pattern | Either | | Java (JUnit/Maven) | `*Test.java` in mirrored package | `src/test/java` mirrors `src/main/java` | Mirrored packages | | Go | `*_test.go` in same directory | Language-enforced co-location | Always co-located | | C# (xUnit/NUnit) | `*Tests.cs` in parallel project | Separate test project | Separate project | | Rust | `#[cfg(test)] mod tests` inline + `tests/` | Inline for unit, `tests/` for integration | Unit: inline, Integration: separate |
Python conftest.py Placement
Place `conftest.py` at the lowest directory where fixtures apply. Pytest discovers from outermost to innermost, enabling hierarchical fixture scoping:
tests/
conftest.py # Session fixtures: DB engine, app instance
unit/
conftest.py # Unit-specific: auto-mock markers
integration/
conftest.py # Integration: real DB fixtures
acceptance/
conftest.py # Acceptance: feature file pathsBDD Feature Files
tests/
features/ # Gherkin .feature files by domain
order/
place_order.feature
payment/
process_payment.feature
step_defs/ # Step implementations by domain concept
conftest.py
order_steps.py
payment_steps.pyOrganize step definitions by domain concept, not by feature file. Shared steps across features prevent duplication.
Hexagonal Architecture Test Tiers
| Tier | Location | Tests | Adapters | |------|----------|-------|----------| | Unit | tests/unit/ | Domain model, value objects, service layer | None (pure) or mock driven ports | | Integration | tests/integration/ | Individual adapters against real infra | Real infrastructure | | Acceptance | t
AI agents that guide you from idea to working code, with human judgment at every gate. nWave runs inside Claude Code. It breaks feature delivery into seven waves (discover, diverge, discuss, design, devops, distill, deliver).
Other skills on nwave.
More skills from other plugins.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
ask-matt
Ask which skill or flow fits your situation. A router over the skills in this repo.
Questions about nw-test-organization-conventions.
- Which coding agents can use nw-test-organization-conventions?
- nw-test-organization-conventions installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.

