1. Overview
This testing strategy outlines a modern, robust and flexible approach for ensuring the reliability and functionality of API platform and corresponding clients.
2. Principles
This strategy is based on a few core principles:
- Acceptance tests should be: concise, accurate, readable, durable, easy to write, resilient to changes in system under test.
- Acceptance tests should be continuously executed for every change in a system under test
- Acceptance tests define what the system should do from user’s perspective. (whether using API for services or web app interactions for clients)
3. Approach
Test Cases. Define test cases that cover various requirements of the system under test.
Domain Specific Language (DSL). Used to describe the test cases in a way that is easy to read and understand. This will make it easier to maintain and update the test suite over time.
Adapters. Use adapters to interact with the system under test. For example, use HTTP drivers to send and receive requests and responses, and use database drivers to access the data stored in the database.
System Under Test. We clearly draw boundary of the system under test. Each service is a system under test, however we do not try to test multiple services together. All dependencies are tested separately.
Test isolation. Ensure sufficient level of test isolation is done in the very beginning by scoping all test cases to be under different users in a system. This will ensure that the test results are reliable and repeatable and can be executed in parallel.
Framework We will use Jest testing framework and Typescript as programming language
This model and approach is inspired by Dave Farley (Author of the book “Continuous Delivery” and creator at Continuous Delivery Youtube Channel) Plus this model has been proven to work really well in large scale applications by us. Plus this model follows architecture and principles behind hexagonal architecture.
4. Frontend Acceptance Tests Boundary
Scope of frontend acceptance tests: Frontend app. External dependencies like internal API or other 3rd party APIs app integrates with are stubbed out.
5. Backend Acceptance Tests Boundary
Tests are done by using API endpoints. External deployables, backend services, 3rd party vendors are mocked out at the network level.
6. Why do we want to define network-level mocks?
For automated acceptance tests we want to provide ability to control state. The better you can control state, the better and easier you can manage expectations.
