Just-in-time testing
To efficiently test and deliver your serverless applications, it is not enough to limit your test coverage; you must also limit the number of times those tests are run.
Serverless and infrastructure as code make it possible and inexpensive to replicate your production environment. However, if a test passes in one non-production envi‐ ronment, it is likely to pass in any others. What really matters is that the code runs as expected in production. This means it is crucial to deliver that code as quickly as possible to your production environment and leverage observability to learn about your application’s behavior under real traffic.
The practice of continuous integration encourages teams to integrate code changes as regularly as possible and is a prerequisite for continuous delivery. The Minimum Viable CD manifesto recommends that “work integrates to the trunk at a minimum daily.”
For a deep dive into continuous integration, be sure to read Martin Fowler’s canonical article from 2006.
Prior to releasing your code, the most important thing is iteration speed and integra‐ tion. The closer you test your code to production, the more valuable the results of these tests will be. You need to shift right on testing and make it later in your software’s delivery lifecycle. In general, you should perform the bulk of testing just before deploying to production; this is when it matters most as the code is closest to being released to your users.
The best time to catch a bug is before it has the chance to impact a large percentage of your users—just in time. This could be in a pre-production staging environment or in production itself, through post-deployment tests like synthetic canaries or efficient, finely tuned alerts.