Spring项目使用mvn site检测：未达100%覆盖率且依赖收敛失败

Hey there, let's break down your two issues with mvn site for your Spring project—dependency convergence errors and missing 100% test coverage. Both are super common in Maven-based projects, so we've got actionable fixes for each:

1. Fixing Dependency Convergence Errors for slf4j-api #

First, let's unpack that error message: you've got two conflicting versions of slf4j-api (1.7.25 and 1.7.5) being pulled into your project. The 1.7.25 comes from json-path (test scope), while 1.7.5 is dragged in by dozer (compile scope). Maven's dependency mediation is flagging this mismatch, which breaks the convergence check.

Here's how to fix it:

• First, map the dependency tree
  Run mvn dependency:tree in your terminal. This will show you every path that pulls in slf4j-api, so you can confirm exactly where those conflicting versions are coming from. It's a quick way to double-check the issue.
• Force a unified version with dependencyManagement
  The cleanest fix is to lock down the slf4j-api version in your project's <dependencyManagement> block. This tells Maven to use the same version everywhere, regardless of what individual dependencies request. Add this to your root pom.xml:

  <dependencyManagement>
      <dependencies>
          <dependency>
              <groupId>org.slf4j</groupId>
              <artifactId>slf4j-api</artifactId>
              <version>1.7.25</version> <!-- Pick the version that works best for your project -->
          </dependency>
      </dependencies>
  </dependencyManagement>
  

  I'd recommend going with 1.7.25 here since it's the newer version used by your test dependency, but you can test both if needed.
• Exclude the conflicting version (alternative)
  If you don't want to use dependencyManagement, you can explicitly exclude the old slf4j-api from the dozer dependency. Add this to your dozer dependency entry:

  <dependency>
      <groupId>net.sf.dozer</groupId>
      <artifactId>dozer</artifactId>
      <version>5.5.1</version>
      <exclusions>
          <exclusion>
              <groupId>org.slf4j</groupId>
              <artifactId>slf4j-api</artifactId>
          </exclusion>
      </exclusions>
  </dependency>
  

• Verify the fix
  Run mvn site again, or use mvn dependency:analyze to check if the convergence error is gone.

2. Getting to 100% Test Coverage #

Missing full coverage is usually about targeting the right gaps—let's focus on practical steps:

• Find the untested code first
  After running mvn site, head to the target/site/jacoco/index.html file (assuming you're using Jacoco, the default coverage tool for Maven site). Open this in a browser, and it'll show you exactly which classes, methods, and even individual lines aren't covered. Common gaps include:
  • Edge cases (null inputs, empty collections, max/min values)
  • Exception handling branches (catch/finally blocks)
  • Private helper methods or utility classes
• Write targeted test cases
  • For edge cases: Add tests that pass extreme values or invalid inputs to your methods. For example, if a method handles lists, test it with an empty list and a null list.
  • For exception branches: Write tests that intentionally trigger exceptions (e.g., passing an invalid ID to a service method that throws NotFoundException). This ensures your error handling logic gets executed.
  • For private methods: If the private method has critical logic, you can use reflection to test it, or refactor it to be package-private (so your test classes in the same package can access it). If it's just a simple helper, you might be able to cover it indirectly via public methods that call it.
• Exclude non-critical code (if needed)
  If you have auto-generated code (like getters/setters) or simple constants that don't need testing, you can exclude them from coverage checks to avoid inflating your gap. Add this to your Jacoco plugin configuration in pom.xml:

  <plugin>
      <groupId>org.jacoco</groupId>
      <artifactId>jacoco-maven-plugin</artifactId>
      <configuration>
          <excludes>
              <exclude>**/model/**/*.class</exclude> <!-- Exclude model classes with only getters/setters -->
              <exclude>**/constants/**/*.class</exclude> <!-- Exclude constant classes -->
          </excludes>
      </configuration>
  </plugin>
  

  Note: Only do this for code that truly doesn't need testing—don't use it as a shortcut for writing proper tests.
• Build incrementally
  Don't try to hit 100% all at once. Start with your core business logic, then work your way through less critical code. For new features, try test-driven development (TDD) to write tests before the code, which ensures coverage from the start.

内容的提问来源于stack exchange，提问作者valik