Testing and validation
In this tutorial we will learn about the basic testing concepts.
Types of tests
This covers three common types of tests that you can use to ensure that your code works correctly:
Unit tests
- Firstly, unit tests are narrowly-scope 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.
However, 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
- Integration tests ensure that components of your code work together and take a reasonable amount of time to complete. For example, Integration tests may be used in Cloud Functions to verify a function’s use of other Google Cloud services.
- The main distinction between unit tests and integration tests for Cloud Functions is that integration tests use less mocking. Actual Cloud events, such as HTTP requests, Pub/Sub messages, or Storage object modifications, should be used to trigger and respond to integration tests.
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.
- Secondly, 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
- First, 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.
- Second, 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 store as environment variables, while secret values (such as database passwords and API keys) should store using Secret Manager.
Reference: Google Documentation