Base for other modules and core components.

Feature	Why?	Demo
Easily create infrastructure using TCIJD (TestContainer Infrastructure) templating + Factories for that	Makes writing and designing tests easier	here
PreStarting mechanismJD for additional performance	Tries to run tests as fast as possible - with a few trade-offs	here
All started containers have a unique human-readable name	Easier identification when tracing or debugging	here
An optimized implementation of NetworkJD	Addresses various problems of the original implementation to speed up tests	here
Safe starting of named containersJD	Ensures that a container doesn't enter a crash loop during retried startups	here
Container Leak detection¹	Prevents you from running out of resources	here
Tracing¹	Makes finding bottlenecks and similar problems easier
Reporting of fatal (Java) crashes during container startup	Easier error diagnosis	here
Fail-fast/Abortable wait strategies	Fail fast when a container crashes - don't wait until the timeout	here

¹ = Active by default due to service loading

Take a look at the minimalistic demo that showcases the components individually.

The configuration is dynamically loaded from (sorted by highest priority)

• Environment variables
  • prefixed with TCI_INFRA-PRE-START_<preStartName>_*
  • prefixed with TCI_INFRA-PRE-START_
  • all properties are in UPPERCASE and use _ instead of . or -
• System properties
  • prefixed with tci.infra-pre-start.<preStartName>.*
  • prefixed with tci.infra-pre-start.

NOTE: * indicates that only some properties support this

Full list of configuration options

Property	Type	Default	Notes
enabled	bool	false	Should PreStarting be enabled?
keep-ready*	int	junit.jupiter.execution.parallel. config.fixed.max-pool-size or 1	How many container should be kept ready for use in the background? Setting this to a value < 0 will effectively disable PreStarting
max-start-simultan*	int	junit.jupiter.execution.parallel. config.fixed.max-pool-size or 1	Maximum amount of containers that should be started simultaneously Setting a negative value will remove this limitation
direct-network-attach-if-possible*	bool	true	true - Directly attaches the container to the network during startup if possible false - Always performs a network-connect as if PreStarting is active. This is slower, however it emulates PreStarting better and may help with finding bugs.
fixate-exposed-ports-if-required*	bool	true	Fixates exposed ports when no direct network attach is possible. This is a workaround for moby/moby#44137.
coordinator.idle-cpu-percent	int	40%	Amount of CPU that needs to be idle to allow PreStarting of containers
coordinator.schedule-period-ms	int	1000 (1s)	How often PreStarting (one factory) should be tried
detect-ending-tests	bool	true	Should PreStarting be stopped when tests are ending?

NOTE: Properties marked with * can additionally can use the preStartName for configuration. Example: tci.infra-pre-start.my-webapp.

The configuration is dynamically loaded from (sorted by highest priority)

• Environment variables
  • prefixed with TCI_LEAK-DETECTION_
  • all properties are in UPPERCASE and use _ instead of . or -
• System properties
  • prefixed with tci.leak-detection.

Full list of configuration options

Property	Type	Default	Notes
enabled	bool	false	Should Leak-Detection be enabled?
stop-timeout-ms	int	~20000 (~20s) actual value depends on cpuSlownessFactor	How long to wait until all infrastructure is stopped after tests have ended