Back to Flutter Inner Source homepage
inner source

Component Tests

Different types of testing are often drawn as a pyramid:

Who Runs What?

If a single team make all the code changes and are operationally responsible for any deployments, that team are responsible for all types of testing.

However, in an inner source model multiple teams make code changes, and each team can be operationally responsible for separate deployments in different environments. This situation is more complex and it is useful to separate test types into two categories:

  1. Reference Tests
  2. Deployment Tests

A single set of Reference Tests are maintained between all teams and these tests must run and pass before a code change is accepted. These tests must run in an environment where the results and logs are visible to all teams (usually GitHub Action workflows). These tests include:

In contrast Deployment Tests are specific to the requirements of an individual deployment. While some collaboration and shared test scripts may occur between teams for such tests this may not always be desireable. These tests are usually run on team-specific infrastructure and the results are not usually immediately visible to other teams. These tests include:

Unit Tests

Unit Tests should run as part of validating any code change. You can also add a minimum code coverage threshold at this point if desired.

Component Tests

COMING SOON Examples of how teams write and run these tests for their own services.

Non-Functional Benchmarks

COMING SOON Examples of how teams write and run these tests for their own services.

Package
← Previous
Standard SDLCS