Capabilities of Testcontainers modules

[HofmeisterAn]

Testcontainers modules allow different kinds of implementations. From a very pure module that only contains the bare minimum configurations, up to a more advanced module that allows extensive customization of the container, application, or services running inside.

Moreover, a module can extend beyond container configurations and include third-party dependencies, offering developers specific APIs to interact with the container, application, or service.

However, we believe that providing the option to configure every small detail of a container, application, or service may not add much value. Ideally, developers should be able to start modules and use them without the need for specific configurations. Modules should cover common use cases, incorporate best practices, and facilitate fast startup of test dependencies.

We believe that sticking to basic modules offers several advantages. Often, there is no need to configure every small detail, for example:

• Configuring ports for applications or services running within containers is not necessary, as developers can access the application or service through the random assigned host port or network alias in container-to-container communication.
• Excluding third-party dependencies can prevent developers from encountering dependency clashes. It is not appropriate to force developers to use specific dependency versions.

We are interested in hearing the thoughts and opinions of our Testcontainers community regarding their vision for modules. What do you consider to be the crucial features required for working effectively with modules?

Note: We understand that companies or applications may have certain restrictions, and that certain features may be essential for some use cases but not for others. However, we believe that the Testcontainers module API provides the flexibility for users to create their own custom implementation to cater to their specific needs.