DR-000023 - Use of Testcontainers for test infrastructure
Overrides/Supersedes
This decision was migrated from the Tech Leads Decision Log as part of a consolidation process. The original decision record can be found here.
RFC
N/A
Stakeholders
- #development
Contributors
Approvers
This decision was made by the Tech Leads group prior to the adoption of current decision making processes within the FOLIO project.
Background/Context
The trend across FOLIO is that teams are adopting testcontainers (https://www.testcontainers.org/) for build-time test infrastructure. For example, RMB, OKAPI, and at least one other module have replaced embedded postgresql with testcontainers, Also, we're starting to see modules which are adopting this for other pieces of infrastructure, e.g. kafka, elasticsearch(?), etc. Given this trend, does FOLIO as a project want to embrace this and encourage teams to follow this approach? For all build-time test infrastructure? Only for specific pieces of infrastructure? What about for UI modules?
Assumptions
List all assumptions that were made when making the decision
Constraints
- It's apparently not possible to run docker simultaneously with vagrant (virtualization issue?)
- One of the drivers for this is that postgres-embedded lacks support for several prominent architectures in version >= postgres 11
- RMB now allows disabling test containers by specifying and external DB for running tests: RMB-826 - Only use postgresTester (testContainers) on "empty" db configuration CLOSED
Rationale
Document the thought process, list reasons that lead to the final decision
Decision
The project is embracing the adoption of using testcontainers for integration test infrastructure.
Implications
- Pros
- Provide a link to RFC when applicable
- Cons
- Provide a link to RFC when applicable
Other Related Resources
What are Testcontainers?
From testcontainers.org:
Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container.
Testcontainers make the following kinds of tests easier:
- Data access layer integration tests: use a containerized instance of a MySQL, PostgreSQL or Oracle database to test your data access layer code for complete compatibility, but without requiring complex setup on developers' machines and safe in the knowledge that your tests will always start with a known DB state. Any other database type that can be containerized can also be used.
- Application integration tests: for running your application in a short-lived test mode with dependencies, such as databases, message queues or web servers.
- UI/Acceptance tests: use containerized web browsers, compatible with Selenium, for conducting automated UI tests. Each test can get a fresh instance of the browser, with no browser state, plugin variations or automated browser upgrades to worry about. And you get a video recording of each test session, or just each session where tests failed.
- Much more! Check out the various contributed modules or create your own custom container classes using
GenericContainer
as a base.
In short, it's used to start/stop docker containers.
Examples of adoption within FOLIO
- https://github.com/folio-org/mod-data-export-spring (postgresql)
- https://github.com/folio-org/raml-module-builder (postgresql)
- https://github.com/folio-org/mod-search (kafka)
- https://github.com/folio-org/okapi (postgresql)
- https://github.com/folio-org/mod-inventory-storage (kafka)
- https://github.com/folio-org/mod-source-record-storage (postgresql)