Test Automation Strategy

Test Automation Strategy

This page describes our approach to test automation. Main questions we are trying to address here:

What tests to write?
What tests do not write?
How much is enough?

Overall approach is inspired by Practical Test Pyramid article.

Main driver to big investment of time in test automation as we don't have dedicated QA/QC resources to perform manual testing.

Test effort break down

Unit tests

We use unit tests to cover core business logic with all possible scenarios in isolation from external systems to shorten feedback loop.

We fully cover all areas in Domain logic and Angular components. TDD approach is highly recommended here.

Integration tests

Specification-based tests

We use BDD approach (using SpecFlow) to write specifications against Services/Domain layer with real dependencies underneath. This will help to make sure that data store and external dependencies interaction works as expected.

Main focus of the use cases is DB Interation with good branch coverage on queries.

End-to-end tests

Those test provide coverage for full application workflow. We use Angular e2e approach on top of Protractor. Number of tests we try to keep small, 2-3 cases per feature.

Main goal here is to verify Backend integration and Web API layer

Additional notes

We intend to keep Web API layer as small as possible so e2e approach can work well here. Therefore in general we do not write unit tests for Web API. Any areas we feel have to be covered, e.g. some infrastructure logic, we may cover with unit tests