Anatomy of testing
Asking for Preferences
The user skipped the clarification, so I'll go with the most common interpretation - software testing anatomy - as a broad overview covering the structure and components of testing.
Anatomy of Testing (Software)
Testing is the practice of verifying that software behaves as expected. Here's a breakdown of its core structure:
1. The Testing Pyramid
The testing pyramid describes the ideal distribution of test types by volume and cost:
/\
/ \ E2E Tests (few, slow, expensive)
/----\
/ \ Integration Tests (moderate)
/--------\
/ \ Unit Tests (many, fast, cheap)
/____________\
- Unit tests - test a single function or class in isolation
- Integration tests - test how two or more modules work together
- End-to-End (E2E) tests - test the full application flow from the user's perspective
2. Anatomy of a Single Test
Every test follows the AAA pattern:
| Phase | Description | Example |
|---|---|---|
| Arrange | Set up inputs, mocks, and preconditions | Create a user object |
| Act | Execute the function/behavior under test | Call login(user) |
| Assert | Verify the output or side effect | Check return value is true |
3. Key Components
Test Subject
The unit, module, or system being tested. Also called the System Under Test (SUT).
Test Double
A stand-in for a real dependency. Types include:
- Mock - verifies calls were made with expected arguments
- Stub - returns pre-defined values
- Spy - wraps real implementation and records calls
- Fake - a working but simplified implementation (e.g., in-memory DB)
- Dummy - a placeholder that's never actually used
Assertion
The statement that defines what "passing" means. If the assertion fails, the test fails.
Test Runner
The engine that discovers and runs tests (e.g., Jest, Pytest, JUnit, Mocha).
Test Suite
A logical grouping of related tests (usually a file or
describe block).4. Types of Testing by Purpose
| Type | Goal |
|---|---|
| Functional | Does the feature work correctly? |
| Regression | Did a change break existing behavior? |
| Smoke | Does the app start and basic flows work? |
| Sanity | Is a specific fix working? |
| Performance | Does the system handle load? |
| Security | Are there vulnerabilities? |
| Acceptance (UAT) | Does it meet business requirements? |
| Exploratory | Manual, unscripted discovery of edge cases |
5. Test Lifecycle
Write Test → Run → Pass/Fail → Debug (if fail) → Refactor → Re-run
In TDD (Test-Driven Development), the cycle is:
- Red - Write a failing test
- Green - Write the minimum code to make it pass
- Refactor - Clean up code while keeping tests green
6. Key Metrics
- Coverage - % of code executed by tests (line, branch, statement, function)
- Test execution time - how long the suite takes to run
- Flakiness - tests that randomly pass/fail without code changes
- Defect escape rate - bugs that reach production despite tests
7. Testing in CI/CD
Tests are typically gated at different pipeline stages:
Commit → Unit Tests → Integration Tests → Deploy to Staging → E2E Tests → Deploy to Prod
Fast tests run first so failures are caught early and cheaply.
Quick Summary
| Concept | One-liner |
|---|---|
| Unit test | Isolated, fast, abundant |
| Integration test | Cross-boundary, moderate |
| E2E test | Real flows, slow, few |
| Mock/Stub | Replace dependencies |
| AAA | Arrange, Act, Assert |
| TDD | Test first, code second |
| Coverage | % of code exercised |
If you had a specific domain in mind (medical testing, academic testing, a specific language/framework), let me know and I'll tailor the answer.
This is a shared conversation. Sign in to Orris to start your own chat.