Cloud Native by Boris Scholl Trent Swanson and Peter Jausovec

Author:Boris Scholl, Trent Swanson, and Peter Jausovec
Language: eng
Format: epub
Publisher: O'Reilly Media, Inc.
Published: 2019-08-28T00:00:00+00:00

When to Run Which Types of Tests

Depending on the CI/CD stage your code is in, you should run different types of tests. The first tests that are usually executed are unit and service/serverless app tests. Unit tests specifically need to be small and execute in a short amount of time. Because they are run before the code merges, they serve as a first level of defense. In case of serverless functions, these are the tests you would run to validate each function separately.

At the next stage, the tests that can be executed either before or after code merge, depending on the complexity and how long it takes to run them, are the service-level tests. The purpose of these tests is to verify the service or the serverless application as a whole. In these tests, you will probably be using mocks instead of real service or serverless app dependencies.

After your code is merged, it is time to run integration tests. These tests verify the integration points between your services and serverless apps. To run these tests, you would deploy the services and serverless applications to their dedicated test environments and run tests between the integration points. Depending on the complexity and number of dependencies, you might want to use mocks for these tests as well. If you don’t have a lot of dependencies, you could provision them in your test environment and use them only for integration tests.

Canary testing is another effective way to continuously evaluate your services and functions. You can run canary tests continuously in each environment. They should mimic the user scenarios as closely as possible and can serve as a warning system for potential issues.

The other types of tests are usually run on their own schedules or as one-offs, and they depend on the type of the services and functions you are developing. For example, it doesn’t make sense to run in-person usability tests every week. These tests would be run as a one-off, probably to validate the ideas and features before releasing them or for getting feedback on features you are planning to work on.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.