🤖
Synthetic testing
"Will it blend?" but with load testing.
Synthetic testing sounds cool and intriguing and vaguely futuristic, but it's really no more than a directed stream of traffic from a non-human source, such as a computer.
Previously we used a smoke test—which is certainly a type of synthetic test—but there is another dimension I want to bring up as well: We can use synthetic testing to continuously verify that our solution keeps performing as expected. In that regard, we can think of it as a kind of "offensive testing" mechanism we submit our live code to.
Running synthetic traffic is something that can certainly stress the existing instance/server/machine/environment, but in our case we could also leverage it during the deployment window (when rolling out a canary deployment) to more fully exercise the system, flushing out any issues. This would also give us a higher probability of hitting any issues—which we may not do during a (for example) 10-minute window with low organic traffic.
🎯 Example: We can use load testing to run various larger-scale synthetic traffic volumes as one-offs to stress the API. Under
tests/load/k6.js you can see our k6 script that we run in CI. The use-case we have here is to ensure that our system responds correctly when provided with a range of inputs rather than just doing the quick poke-and-feel we did with the smoke test.Synthetics can be run with almost anything: Examples include a regular API client like Insomnia, a load testing tool like k6 or Artillery, a SaaS product like Checkly, or a managed tool like AWS CloudWatch Synthetics. Even
curl works fine! If you want to set something up to continuously run against your endpoint, I recommend using an easy-to-use tool like CloudWatch Canaries or Checkly, directing them to your endpoint.Last modified 1yr ago