# Testing Requirements

## Test Strategy

Choose tests according to the changed behavior and repository architecture:

1. **Unit tests** for focused functions, utilities, and components.
2. **Integration tests** for boundaries such as APIs, databases, file systems, and service interactions.
3. **End-to-end tests** for critical user flows when the project has an E2E harness.

Do not require every test category for a change that cannot exercise it meaningfully. Follow the repository's configured coverage threshold; when establishing a new threshold, target at least 80% while prioritizing behavior and risk over a raw number.

## Test-Driven Development

For new behavior and bug fixes:

1. Write or update a focused test.
2. Run it and confirm it fails for the expected reason.
3. Implement the minimum correct change.
4. Run the test and confirm it passes.
5. Refactor while keeping the suite green.
6. Run broader tests and coverage checks.

Use the project's existing package manager and test runner. Inspect project configuration rather than assuming a command.

## Troubleshooting Failures

1. Reproduce the smallest failing scope.
2. Check isolation, fixtures, timing, and mocks.
3. Fix implementation defects rather than weakening correct assertions.
4. Update a test only when the expected behavior was wrong or intentionally changed.
5. Re-run the broader relevant suite after the focused fix.

Load a matching testing skill when the current Pi session exposes one. A Pi extension may provide specialized testing tools, but Pi does not include a named TDD agent by default.

## Test Structure

Prefer Arrange-Act-Assert and descriptive behavior names:

```typescript
test("returns an empty array when no records match", () => {
  // Arrange
  const records = [];

  // Act
  const result = filterRecords(records, "query");

  // Assert
  expect(result).toEqual([]);
});
```

Tests should be deterministic, isolated, and focused on observable behavior.