> For the complete documentation index, see [llms.txt](https://framework.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://framework.aic.io/technical-guidelines-code-standards-and-tech-stack/test-driven-development-and-quality-engineering/test-pyramid-and-test-types.md).

# Test Pyramid and Test Types

## Purpose

AIC uses a balanced test strategy. Fast unit tests provide design feedback. Integration tests prove infrastructure behaviour. Contract and acceptance tests protect external promises. UI tests are used selectively.

## Test Pyramid

```
        Exploratory / manual assurance
       UI and end-to-end tests
      Contract and API tests
     Integration tests
    Unit tests
```

## Test Types

| Test type   | Purpose                                              |       Speed | Owner          |
| ----------- | ---------------------------------------------------- | ----------: | -------------- |
| Unit        | Verify isolated business logic                       |        Fast | Developer      |
| Component   | Verify a module with limited dependencies            | Fast/medium | Developer      |
| Integration | Verify real infrastructure boundaries                |      Medium | Developer/team |
| Contract    | Verify API/provider/consumer compatibility           |      Medium | Team           |
| End-to-end  | Verify critical journeys                             |        Slow | Team/QA        |
| Performance | Verify throughput, latency and resource use          |        Slow | Team           |
| Security    | Verify access, validation and common security issues |    Variable | Team/security  |
| Exploratory | Human investigation                                  |    Variable | QA/user/team   |

## AIC Minimum Test Set

Every production project MUST have:

* unit tests for business rules
* integration tests for persistence and external adapters where practical
* API tests for web APIs
* security tests for authorization boundaries
* regression tests for fixed defects
* pipeline execution of tests

## Test Smell Indicators

Investigate when:

* tests are flaky
* tests require manual setup
* tests depend on local machine state
* tests assert too many things
* tests break on harmless refactoring
* test data is unclear
* integration tests silently use production resources

## Pipeline Split

A typical pipeline separates:

* build validation tests on every PR
* full integration tests on merge
* nightly performance/security checks where appropriate
* release acceptance tests before deployment