Managing test dependencies in Spring Boot applications can be surprisingly complex, especially when we need specific versions of testing libraries or want to understand how Spring Boot coordinates various testing frameworks. Many developers focus on production dependency management while overlooking the sophisticated test dependency management that Spring Boot provides out of the box.
Spring Boot’s parent POM doesn’t just manage production libraries like JDBC drivers and web frameworks—it also provides comprehensive management for testing dependencies. Understanding how this works helps us maintain cleaner POMs, avoid version conflicts, and ensure our testing libraries work together seamlessly.
Spring Boot’s Test Dependency Management
The Spring Boot parent POM manages versions for all major testing libraries through its dependency management section.
When we include spring-boot-starter-test, we get a curated collection of testing libraries without needing to specify versions:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.5.0</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> |
This single dependency brings in JUnit 5, Mockito, AssertJ, Hamcrest, Spring Test, and several other testing libraries. The parent POM ensures these libraries are compatible versions that have been tested together by the Spring Boot team.
We can verify which versions are being managed by running:
|
1 |
mvn dependency:tree |
This shows us the complete test dependency tree with all managed versions. For example, we might see:
|
1 2 3 4 5 6 7 8 9 10 11 |
[INFO] \- org.springframework.boot:spring-boot-starter-test:jar:3.5.0:test [INFO] +- org.springframework.boot:spring-boot-test:jar:3.5.0:test [INFO] +- org.springframework.boot:spring-boot-test-autoconfigure:jar:3.5.0:test [INFO] +- com.jayway.jsonpath:json-path:jar:2.9.0:test [INFO] | \- org.slf4j:slf4j-api:jar:2.0.17:compile [INFO] +- jakarta.xml.bind:jakarta.xml.bind-api:jar:4.0.2:test [INFO] | \- jakarta.activation:jakarta.activation-api:jar:2.1.3:test [INFO] +- net.minidev:json-smart:jar:2.5.2:test [INFO] | \- net.minidev:accessors-smart:jar:2.5.2:test [INFO] | \- org.ow2.asm:asm:jar:9.7.1:test [INFO] +- org.assertj:assertj-core:jar:3.27.3:test |
Overriding Test Library Versions with Maven Properties
Sometimes we need a specific version of a testing library – perhaps to access newer features or fix compatibility issues with other tools.
Instead of excluding and re-including dependencies, Spring Boot provides Maven properties to override specific versions.
To find the available property names, we need to examine the Spring Boot parent POM. We can navigate to the Spring Boot parent POM in our IDE or check GitHub.
The properties section contains entries like:
|
1 2 3 4 5 6 7 |
<properties> <mockito.version>5.7.0</mockito.version> <junit-jupiter.version>5.10.1</junit-jupiter.version> <assertj.version>3.24.2</assertj.version> <selenium.version>4.15.0</selenium.version> <htmlunit.version>3.9.0</htmlunit.version> </properties> |
To override Mockito’s version in our project, we simply add the property to our POM:
|
1 2 3 4 |
<properties> <java.version>21</java.version> <mockito.version>5.8.0</mockito.version> </properties> |
This approach is much cleaner than manual exclusions and inclusions:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
<!-- Avoid this approach --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> <exclusions> <exclusion> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <version>5.8.0</version> <scope>test</scope> </dependency> |
The property override method maintains the dependency structure while simply changing the version Spring Boot uses.
Extended Testing Library Management
Spring Boot’s parent POM manages far more testing libraries than those included in spring-boot-starter-test. This comprehensive management ensures compatibility across the entire testing ecosystem.
For web testing, we might add Selenium and HTMLUnit:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-java</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.htmlunit</groupId> <artifactId>htmlunit</artifactId> <scope>test</scope> </dependency> </dependencies> |
Notice we don’t specify versions – Spring Boot manages these automatically. The parent POM ensures that Selenium works properly with the included version of HtmlUnit and other web testing libraries.
The Critical Importance of Test Scope
One crucial aspect of managing test dependencies is ensuring they’re properly scoped. The test scope prevents these libraries from being included in our production JAR, keeping our application lightweight and avoiding potential security vulnerabilities.
Consider what happens without proper scoping:
|
1 2 3 4 5 |
<!-- WRONG: Missing test scope --> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> </dependency> |
This dependency would be included in our production JAR, unnecessarily increasing its size and potentially introducing security vulnerabilities. Mockito, for instance, includes byte code manipulation libraries that have no place in production.
We can verify our scoping is correct by examining the built JAR:
|
1 2 |
mvn package jar -tf target/myapp-1.0.0.jar | grep mockito |
If this command returns any results, we have a scoping problem.
The correct approach always includes the test scope:
|
1 2 3 4 5 6 7 8 9 10 11 |
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-java</artifactId> <scope>test</scope> </dependency> |
Summary of Managing Test Dependencies
Spring Boot’s parent POM provides comprehensive management for both production and testing dependencies, ensuring compatibility and reducing the complexity of our Maven configuration. By leveraging this management system, we can include testing libraries without specifying versions, override specific versions using Maven properties when needed, and maintain clean separation between test and production dependencies.
The key benefits of this approach include simplified dependency management, guaranteed compatibility between testing libraries, and easy version overrides without complex exclusions. Most importantly, proper use of test scoping ensures our production artifacts remain lean and secure.
Understanding these mechanisms allows us to build more maintainable test suites while avoiding common pitfalls like version conflicts and bloated production JARs. By embracing Spring Boot’s dependency management for testing, we can focus on writing effective tests rather than wrestling with dependency configuration.
Joyful testing,
Philip
