Testing quality gates

Fail Fast


We achieve a level of automation that would give enough confidence to allow the majority of builds to automatically deploy (via the release pipeline) directly into production.

Quality Gate 1: Developer Unit Tests

All directly executable behaviour should be fully covered by unit tests, e.g.

  • controller actions
  • public methods
  • shared functions
  • extension methods
  • etc.

Unit tests should run in memory entirely under the control of the test logic – there should be no reliance on external dependencies such as the file system, database, windows services etc.

These tests should run continuously during the development process (NCrunch will ensure this happens) and during the build process.

Quality Gate 2: Developer Integration Tests

Interaction between components should be validated with integration tests. Integration tests do not run continuously. These tests should be run manually before creating PR and will run as part of the build process.

Quality Gate 3: Tester Regression Tests

The 3rd level of tests take the form of automated screen tests. Currently these are being developed using Silk4Net but this could change. These tests should run after each deployment to both the CI and Test environments.

Quality Gate 4: E2E Smoke Test

The final level of tests are read only, happy path tests that do not change any data but ensure all the system dependencies are in place and working. These tests should run after each deployment to all environments.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.