Use integration testing
When we discuss "integration testing", we mean something beyond unit testing. Your team may call it by another name.
In general this means running your application—possibly with fakes, stubs, mocks, spies, dummies, or doubles—for external dependencies (databases, remote REST calls, other services, the file system, etc), and running tests against higher-level functionality in your program (think "frontdoor" calls into your code) but not starting up external dependencies themselves, or calling to existing running services.
Think of CI: "integration tests" are those which do not need your CI to provide other services. Contrast this with System Testing which involves live tests against external systems. Both are valuable: but your development goes faster when local testing can rely on substitions ("mocks") for remote resources.
An example is testing STDOUT and STDERR for a command-line application.
(If you are in Spring Framework/Boot-land, use controller tests for your REST
services.)
Unlike src/main/java and src/test/java, there is no generally agreed
convention for where to put integration tests.
This project keeps integration tests in src/integrationTest/java
for simplicity of presentation, and they are named "*IT.java".
This pattern is represented in build.gradle and pom.xml.
A more sophisticated approach may make sense for your project.
If you'd like to keep your integration tests in a separate source root from unit tests, consider these plugins:
- For Gradle, use [native Gradle to add new test
Caution: This project duplicates
ApplicationIT.javaandApplicationTest.javareflecting the split in philosophy between Gradle and Maven for integration tests. Clearly in a production project, you would have only one of these. sets](https://docs.gradle.org/current/userguide/java_testing.html#sec:configuring_java_integration_tests). (Previous versions of this project used the excellenttestsetsplugin, however, it does not support Gradle 8) - For Maven, use the Maven Failsafe Plugin
Caution: This project duplicates
ApplicationIT.java
and
ApplicationTest.java
reflecting the split in philosophy between Gradle and Maven for integration
tests.
Clearly in a production project, you would have only one of these.
- For Maven projects, Apache maintains Failsafe and Surefire plugins as a pair,
and share the same version numbers.
This project uses a shared
maven-testing-plugins.versionproperty - Baeldung has a good introduction article on Maven Failsafe
TODO: Placeholder section
See the code repo for working examples.
This work is dedicated/deeded to the public following laws in jurisdictions
for such purpose.
The principal authors are: