6. Test environments and test data
Testing should be performed in an environment and with data that are appropriate for the purpose of the test. The environment should be sufficiently similar to the target environment to make the test results meaningful, while keeping testing separate from production whenever possible.
6.1 Test environments
Different environments can be used for different stages and types of testing. A project may, for example, have separate environments for development, integration testing, acceptance testing, and production.
The number and purpose of environments depend on the size, architecture, and risks of the application. Not every application needs several separate test environments.
When planning test environments, consider:
- which testing activities are performed in each environment
- how closely the environment should resemble production
- which external services and integrations are available
- how the environment is configured and maintained
- how the application and test data are deployed or reset
- who has access to the environment
- whether automated tests can run reliably in the environment
Testing should generally be performed before changes are deployed to production. Production should not be used as the primary test environment.
Some testing may nevertheless need to take place in production, for example smoke tests after deployment. Such tests should be carefully designed so that they do not modify real data, disrupt the service, or affect users unnecessarily.
6.2 University of Helsinki test services and environments
The University of Helsinki provides test environments and services for testing applications and integrations. When a dedicated test service is available, it should generally be used instead of connecting development and test applications directly to production services.
Available test environments include:
- University login test service: A separate test environment is available for developing and testing authentication using OpenID Connect (OIDC) and SAML2. Developers can register test applications and manage test users through the SP Registry. See login.helsinki.fi: Test service
- For test users generation see script: https://version.helsinki.fi/test-users/create-users
- OpenShift test environment:
- API gateway test environment
Virtual server test environment: When an application is hosted on a virtual server, a separate server should be ordered and configured for testing. The test server can be configured with more restricted access than the production server, for example by limiting privileges and open ports. If multiple environments are needed, order the required servers at the same time.
Database Test and production environments should not share the same database. A separate database should be ordered for each environment. For example, if the application has development, test, and production environments, each environment should have its own database.
Other University services (for example Efecte) may provide their own test or development environments. Check the documentation of the service or integration before connecting an application to its production environment.