ln-743-test-infrastructure
Sets up test infrastructure with Vitest, xUnit, and pytest. Use when adding testing frameworks and sample tests to a project.
Best use case
ln-743-test-infrastructure is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Sets up test infrastructure with Vitest, xUnit, and pytest. Use when adding testing frameworks and sample tests to a project.
Teams using ln-743-test-infrastructure should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/ln-743-test-infrastructure/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How ln-743-test-infrastructure Compares
| Feature / Agent | ln-743-test-infrastructure | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Sets up test infrastructure with Vitest, xUnit, and pytest. Use when adding testing frameworks and sample tests to a project.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
SKILL.md Source
> **Paths:** File paths (`shared/`, `references/`, `../ln-*`) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root. If `shared/` is missing, fetch files via WebFetch from `https://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path}`.
# ln-743-test-infrastructure
**Type:** L3 Worker
**Category:** 7XX Project Bootstrap
Sets up testing frameworks, coverage tools, and sample tests for projects.
---
## Purpose & Scope
**Does:**
- Detects project stack to choose appropriate test framework
- Creates test configuration files
- Sets up coverage reporting with thresholds
- Creates sample tests demonstrating patterns
- Verifies test suite runs successfully
**Does NOT:**
- Configure linters (ln-741 does this)
- Set up pre-commit hooks (ln-742 does this)
- Write actual application tests (developers do this)
---
## Supported Stacks
| Technology | Test Framework | Coverage Tool | Config File |
|------------|---------------|---------------|-------------|
| TypeScript/React | Vitest | v8/Istanbul | `vitest.config.ts` |
| .NET | xUnit | Coverlet | `*.Tests.csproj` |
| Python | pytest | pytest-cov | `pytest.ini` or `pyproject.toml` |
---
## Phase 1: Check Existing Tests
Before creating test infrastructure, check what exists.
**Files to Check:**
| Stack | Test Indicators |
|-------|-----------------|
| TypeScript | `vitest.config.*`, `jest.config.*`, `*.test.ts`, `*.spec.ts` |
| .NET | `*.Tests.csproj`, `*.IntegrationTests.csproj` |
| Python | `pytest.ini`, `conftest.py`, `tests/`, `test_*.py` |
**Decision Logic:**
1. If complete test setup exists: **SKIP** (inform user)
2. If partial setup: **ASK** to extend or replace
3. If no tests: **CREATE** from templates
---
## Phase 2: Create Test Configuration
### TypeScript/React (Vitest)
Create `vitest.config.ts`:
- Use v8 coverage provider (faster than Istanbul)
- Configure jsdom environment for React
- Set coverage thresholds (80% minimum)
- Create setup file for testing-library
**Dependencies:**
```
npm install -D vitest @vitest/coverage-v8 @testing-library/react @testing-library/jest-dom jsdom
```
### .NET (xUnit)
Create test project:
```bash
dotnet new xunit -n {Project}.Tests
dotnet sln add tests/{Project}.Tests
```
**Dependencies (in .csproj):**
- Microsoft.NET.Test.Sdk
- xunit
- xunit.runner.visualstudio
- Moq
- FluentAssertions
- coverlet.collector
### Python (pytest)
Add to `pyproject.toml` or create `pytest.ini`:
- Configure test discovery paths
- Set coverage thresholds (80% minimum)
- Configure coverage reporting
**Dependencies:**
```
pip install pytest pytest-cov pytest-asyncio
# OR with uv:
uv add --dev pytest pytest-cov pytest-asyncio
```
---
## Phase 3: Create Test Directory Structure
### TypeScript
```
src/
├── components/
│ ├── Button.tsx
│ └── Button.test.tsx # Co-located tests
├── test/
│ └── setup.ts # Test setup file
```
### .NET
```
tests/
├── {Project}.Tests/
│ ├── Controllers/
│ │ └── SampleControllerTests.cs
│ ├── Services/
│ └── {Project}.Tests.csproj
└── {Project}.IntegrationTests/ # Optional
```
### Python
```
tests/
├── conftest.py # Shared fixtures (from conftest_template.py)
├── unit/
│ └── test_sample.py
└── integration/ # Optional
```
For FastAPI/async projects, generate `conftest.py` from `conftest_template.py` with shared async HTTP client fixture. Adapt the app import path to match the project.
---
## Phase 4: Create Sample Tests
Create one sample test per stack demonstrating:
- AAA pattern (Arrange-Act-Assert)
- Test naming conventions
- Basic assertions
- Framework-specific patterns
### TypeScript Sample Test
Shows:
- render() from testing-library
- screen queries
- Jest-dom matchers
### .NET Sample Test
Shows:
- [Fact] attribute
- Moq for mocking
- FluentAssertions syntax
### Python Sample Test
Shows:
- pytest fixtures
- assert statements
- parametrized tests (optional)
---
## Phase 5: Verify Test Run
After setup, verify tests work.
**TypeScript:**
```bash
npm test
npm run test:coverage
```
Expected: Sample test passes, coverage report generated
**.NET:**
```bash
dotnet test
dotnet test --collect:"XPlat Code Coverage"
```
Expected: Sample test passes, coverage collected
**Python:**
```bash
pytest
pytest --cov=src --cov-report=term-missing
```
Expected: Sample test passes, coverage report shown
**On Failure:** Check test configuration, dependencies, verify sample test syntax.
---
## Coverage Requirements
| Metric | Minimum | Target |
|--------|---------|--------|
| Lines | 70% | 80% |
| Branches | 70% | 80% |
| Functions | 70% | 80% |
| Statements | 70% | 80% |
Configure CI to fail if coverage drops below thresholds.
---
## Critical Rules
> **RULE 1:** Coverage thresholds MUST be configured. No exceptions.
> **RULE 2:** Sample tests MUST pass. Don't create broken examples.
> **RULE 3:** Use AAA pattern (Arrange-Act-Assert) in all sample tests.
> **RULE 4:** Co-locate unit tests with source (TypeScript) or use tests/ directory (.NET, Python).
---
## Definition of Done
- [ ] Test framework installed and configured
- [ ] Coverage tool configured with 80% threshold
- [ ] Test directory structure created
- [ ] Sample test created and passing
- [ ] `npm test` / `dotnet test` / `pytest` runs successfully
- [ ] Coverage report generates
- [ ] User informed of:
- How to run tests
- Where to add new tests
- Coverage requirements
---
## Reference Files
| File | Purpose |
|------|---------|
| [vitest_template.ts](references/vitest_template.ts) | Vitest config template |
| [vitest_setup_template.ts](references/vitest_setup_template.ts) | Test setup file |
| [react_test_template.tsx](references/react_test_template.tsx) | React component test |
| [xunit_csproj_template.xml](references/xunit_csproj_template.xml) | .NET test project |
| [xunit_test_template.cs](references/xunit_test_template.cs) | xUnit test example |
| [pytest_config_template.toml](references/pytest_config_template.toml) | pytest config |
| [pytest_test_template.py](references/pytest_test_template.py) | pytest test example |
| [conftest_template.py](references/conftest_template.py) | Shared async fixtures (FastAPI) |
| [testing_guide.md](references/testing_guide.md) | Testing best practices |
---
## Error Handling
| Error | Cause | Resolution |
|-------|-------|------------|
| Vitest not found | Not installed | `npm install -D vitest` |
| jsdom errors | Missing dependency | `npm install -D jsdom` |
| xUnit discovery fails | SDK version mismatch | Update Microsoft.NET.Test.Sdk |
| pytest not found | Not in PATH | `pip install pytest` |
| Coverage 0% | Wrong source path | Check coverage.include config |
---
**Version:** 3.0.0
**Last Updated:** 2026-03-18Related Skills
ln-782-test-runner
Executes all test suites and reports results with coverage. Use when verifying that test infrastructure works after bootstrap.
ln-637-test-structure-auditor
Checks test file organization, directory layout, test-to-source mapping, domain grouping, co-location. Use when auditing test structure.
ln-636-manual-test-auditor
Checks manual test scripts for harness adoption, golden files, fail-fast, config sourcing, idempotency. Use when auditing manual test quality.
ln-635-test-isolation-auditor
Checks test isolation (API/DB/FS/Time/Network), determinism, flaky tests, order-dependency, anti-patterns. Use when auditing test isolation.
ln-634-test-coverage-auditor
Identifies missing tests for critical paths (money, security, data integrity, core flows). Use when auditing test coverage gaps.
ln-633-test-value-auditor
Scores each test by Impact x Probability, returns KEEP/REVIEW/REMOVE decisions. Use when auditing test value and pruning low-value tests.
ln-632-test-e2e-priority-auditor
Validates E2E coverage for critical paths (money, security, data integrity). Risk-based prioritization. Use when auditing E2E test coverage.
ln-631-test-business-logic-auditor
Detects tests validating framework/library behavior instead of project code. Use when auditing test business logic focus.
ln-630-test-auditor
Coordinates test suite audit across business logic, E2E coverage, value, isolation, manual quality, and structure. Use when auditing entire test suite.
ln-523-auto-test-planner
Plans automated tests (E2E/Integration/Unit) using Risk-Based Testing after manual testing. Use when Story needs a test task with prioritized scenarios.
ln-522-manual-tester
Performs manual testing of Story AC via executable bash scripts in tests/manual/. Use when Story implementation needs hands-on AC verification.
ln-521-test-researcher
Researches real-world problems, competitor solutions, and customer complaints for a feature domain. Use before test planning to ground tests in actual user pain points.