Testing frameworks (load/unit/integration)
In this we will understand about Testing frameworks (load/unit/integration).
Types of tests
This guide covers three common types of tests that you can use to ensure that your code works correctly:
Unit tests
- Firstly, unit tests are narrowly-scoped tests for small, specific parts of your code. These tests can quickly verify assumptions made during the development process, such as handling edge cases and input validation.
- Secondly, by design, unit tests do not test integration with any external dependencies, such as Cloud Functions itself or other Google Cloud components. You can use your mocking framework to create mock versions of external dependencies.
- Lastly, for HTTP functions, tests should mock the wrapping HTTP framework. Confirm the function’s behavior by combining testing and mocking frameworks and comparing your function’s results to expected values.
Integration tests
- Firstly, integration tests validate the interaction between parts of your code and typically take a moderate amount of time to complete. For example, in Cloud Functions, integration tests can be used to test a function’s usage of other Google Cloud services such as Datastore or Cloud Vision.
- Secondly, the primary difference between unit tests and integration tests for Cloud Functions is that integration tests involve less mocking than unit tests. Integration tests should trigger and respond to actual Cloud events such as HTTP requests, Pub/Sub messages, or Storage object changes.
- Lastly, you can run integration tests locally using a shim.
System tests
- Firstly, system tests are more complex tests that validate the behavior of your Cloud Function across multiple Google Cloud components in an isolated test environment.
- Next, Deploy your Cloud Function to a test environment and test its functionality by triggering the appropriate events. Validate your function by reading the logs or checking for the desired behavior.
Best practices for testing environments
- Firstly, be sure to isolate your development, testing, and production environments. In order to guarantee hermetic builds, we recommend programmatically provisioning test resources with their own unique GCP projects and/or resource names.
- Secondly, we recommend assigning resources used by system tests globally unique names to prevent concurrent tests from interfering with each other. You can do this by programmatically creating and deleting the required resources before and after each test run.
- Finally, we recommend keeping configuration values separate from your codebase. Non-secret values can be stored as environment variables, while secret values (such as database passwords and API keys) should be stored using Secret Manager.
test – Run gsutil unit/integration tests (for developers)
Synopsis
gsutil test [-l] [-u] [-f] [command command…]
The gsutil test command performs the unit and integration tests for gsutil. An in-memory mock storage service implementation is used in the unit tests. While the integration tests use the boto configuration file’s chosen API to make requests to the production service.
To run both the unit tests and integration tests, run the command with no arguments:
gsutil test
Secondly, to run the unit tests only (which run quickly):
gsutil test -u
Regardless of whether the top-level -m option is present, tests run in parallel. Limit the number of concurrent tests to ten at a time:
gsutil test -p 10
Next, to force tests to run sequentially:
gsutil test -p 1
After that, to have sequentially-run tests stop running immediately when an error occurs:
gsutil test -f
Options
-b Test against US buckets from across the country. By default, tests in us-central1 are conducted against regional buckets.
-c Output coverage information.
-f Exit on first sequential test failure.
-l List available tests.
-p N Run at most N tests in parallel. The default value is 5.
-s Run tests against S3 instead of GS.
-u Only run unit tests.
Reference: Google Documentation, Doc 2