Note
These docs are a work in progress. While conceptually correct, the diagrams/code samples on this page might not be 100% in line with the current implementation in Copper.
Load testing
- Prove architecture
- Vertical slice testing
- Confirm platform decision
- Integration with 3rd party platforms e.g. BlazeMeter
Context and problem
There is a misconception that load tests can only be performed when there is an entire stack implemented and is often, if at all, planned at the end of a project, right before delivery. This makes it impossible to detect problems in design early on, which might improve system performance greatly. After all, most severe performance issues, are a result of poor (detailed) design.
Solution
By having a strategy to incorporate load testing at a very early stage (event one of the first development tasks in the project) we reduce the risk of not meeting performance requirements at the end.
Due to the generated project structure, the Test Host and Test Harness, it requires implementing just the service contracts, which are part of the detailed design effort to enable full end-to-end load testing of the system.
We load test our systems by implementing the call chains and adding artificial wait times in locations where we except to have IO or integration points with a resource which might not be able to respond quickly. By simulating these wait times, we can also determine minimal requirements for our third-parties that need to be integrated. If the call chains are implemented, we trigger use cases by implementing the scenario in a Client which can be called by a HTTP trigger.
Most load testing tooling is able to do HTTP requests, so by ensuring the entire call chain is hit and returns within a single HTTP call we can leverage powerful load testing applications such as BlazeMeter, SoapUI, Postman or JMeter. One-way calls are awaited by awaiting the business event in the same scenario.
Options
