Invos

01_testing_strategy

3 min read

Testing Strategy

Our testing strategy is based on the “testing pyramid,” which emphasizes a strong foundation of unit tests, a healthy layer of integration tests, and a smaller, more focused set of end-to-end tests. Quality is a shared responsibility of the entire team.

The Testing Pyramid

      /\
     /  \  End-to-End Tests
    /----\
   /      \ Integration Tests
  /--------\
 /          \ Unit Tests
/____________\```

- **Unit Tests (Foundation):**
  - **Goal:** To test individual functions, components, or modules in isolation. See our [Unit Testing Guidelines](./02_unit_testing_guidelines.md) for more details.
  - **Speed:** Very fast.
  - **Scope:** Small and focused.
  - **Who writes them:** Developers.

- **Integration Tests (Middle Layer):**
  - **Goal:** To test how multiple units work together. See our [Integration Testing Guidelines](./03_integration_testing_guidelines.md) for more details.
  - **Speed:** Slower than unit tests.
  - **Scope:** A group of related components or a specific feature.
  - **Who writes them:** Developers.

- **End-to-End (E2E) Tests (Top Layer):**
  - **Goal:** To test the entire application from the user's perspective, simulating real user flows. See our [End-to-End Testing Guidelines](./04_end_to_end_testing_with_playwright_or_cypress.md) for more details.
  - **Speed:** Slow and can be brittle.
  - **Scope:** Critical user journeys (e.g., login, checkout, creating a post).
  - **Who writes them:** Developers or QA engineers.

## Our Tech Stack for Testing

- **Unit/Integration Testing:** **Jest** and **React Testing Library**.
- **End-to-End Testing:** **Playwright** or **Cypress**.
- **Test Runner:** Tests are run via `npm test` or `yarn test`.

## When and Where Tests are Run

1.  **Local Development:** Developers should run tests locally as they are working on a feature.
    ```bash
    # Run all tests
    npm test

    # Run tests in watch mode
    npm test -- --watch
    ```

2.  **Pre-commit Hooks:** We use Husky to run relevant tests (and the linter) before a commit is created. This prevents broken code from being pushed to the repository.

3.  **Continuous Integration (CI):**
    - The full test suite (unit, integration, and E2E) is run automatically on every Pull Request.
    - A PR cannot be merged unless all tests are passing.
    - This is our main safety net to prevent regressions.

## User Acceptance Testing (UAT)

- **Goal:** To allow the client or end-users to validate that the application meets their requirements.
- **When:** UAT is typically conducted on a staging or preview environment before a major release.
- **Process:** The project manager will coordinate with the client to provide a UAT plan and a list of scenarios to test. Feedback and bugs are reported through our standard [Bug Reporting and Triage](./05_bug_reporting_and_triage.md) process.

## Performance Testing

- **Goal:** To ensure the application is fast, responsive, and can handle the expected load.
- **Process:** We conduct performance testing as described in our [Performance Testing Guidelines](./06_performance_testing.md). This includes measuring metrics like Load Time, Time to First Byte (TTFB), and Core Web Vitals.

By following this multi-layered strategy, we aim to build high-quality, reliable applications and catch bugs as early as possible in the development lifecycle.

Graph View

Backlinks