如何从Java库引入ArchUnit测试并在Dropwizard微服务构建中执行？

Absolutely—this is a standard practice for maintaining consistent architecture across a suite of microservices, and it’s totally feasible with ArchUnit and Java build tools. Let’s walk through exactly how to set this up for your Dropwizard services:

First, create a standalone Java library project (Maven or Gradle) to house your reusable ArchUnit rules. This keeps all your architecture checks centralized and easy to update.

• Add dependencies: Include ArchUnit, your preferred test framework (JUnit 5 is recommended for better annotation support), and the Dropwizard API JARs (since you’re testing Dropwizard-specific components like resources or health checks) in your build file.
• Write reusable rules: Package your ArchUnit checks in a class (or multiple classes) using the @ArchTest annotation. Make these rules generic enough to apply across all your services, but flexible where needed. For example:

  public class DropwizardArchitectureEnforcer {
      // Enforce all resource classes extend Dropwizard's ManagedResource
      @ArchTest
      public static final ArchRule resources_must_extend_managed_resource =
          classes().that().resideInAPackage("..resource..")
              .should().beAssignableTo(ManagedResource.class);
  
      // Ensure all health checks implement Dropwizard's HealthCheck
      @ArchTest
      public static final ArchRule health_checks_must_implement_health_check =
          classes().that().resideInAPackage("..health..")
              .should().beAssignableTo(HealthCheck.class);
  
      // Block service layer classes from directly accessing web layer components
      @ArchTest
      public static final ArchRule service_layer_cannot_depend_on_web_layer =
          noClasses().that().resideInAPackage("..service..")
              .should().dependOnClassesThat().resideInAPackage("..resource..");
  }
  

• Publish the library: Deploy this library to your internal artifact repository (like Nexus or Artifactory), or install it locally with mvn install for development testing.

Each service needs to pull in the shared library as a test-scoped dependency (since the rules only run during the test phase, not in production).

Maven Example (pom.xml) #

<dependency>
    <groupId>your.company.group</groupId>
    <artifactId>archunit-shared-rules</artifactId>
    <version>1.0.0</version>
    <scope>test</scope>
</dependency>

Gradle Example (build.gradle) #

testImplementation 'your.company.group:archunit-shared-rules:1.0.0'

There are two straightforward ways to run the shared rules in each service’s build pipeline:

Option 1: Auto-Discovery (Recommended) #

If you’re using JUnit 5, ArchUnit’s @ArchTest annotations are automatically picked up by the test runner—no extra code needed. As long as the shared library is in the test classpath, your build tool (Maven Surefire or Gradle Test task) will execute all the rules during the test phase.

• Pro tip: If you need to exclude specific rules for a service, use ArchUnit’s @ArchTag annotation to tag rules in the shared library, then exclude those tags in the service’s test configuration. For example:
  1. Tag a rule in the shared library:

     @ArchTag("dropwizard-resource")
     @ArchTest
     public static final ArchRule resources_must_extend_managed_resource = ...;
     

  2. Exclude it in the service’s test class:

     @ExcludeTags("dropwizard-resource")
     public class LocalArchitectureTests {
         // Local custom rules here
     }
     

Option 2: Explicit Import (For Fine-Grained Control) #

If you want to explicitly choose which rules to run, create a test class in each service that imports the shared rules:

@ExtendWith(ArchUnitExtension.class)
public class SharedArchitectureTests {
    // Import all @ArchTest rules from the shared library
    @ArchTest
    static final ArchRule[] shared_rules = DropwizardArchitectureEnforcer.class.getDeclaredFields();
}

This class will execute all the shared rules, and your build tool will run it just like any other test class.

By default, both Maven and Gradle will fail the build if any test (including ArchUnit rules) fails. To make this explicit (and avoid accidental overrides), you can tweak your build configuration:

Maven Surefire Plugin #

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>3.2.5</version>
    <configuration>
        <failIfNoTests>true</failIfNoTests> <!-- Ensure shared tests are run -->
        <testFailureIgnore>false</testFailureIgnore> <!-- Fail build on test failure -->
    </configuration>
</plugin>

Gradle #

Gradle’s test task defaults to failing the build on test failure. If you’ve modified this behavior, reset it with:

test {
    failOnFailure = true
}

If some services need to adjust shared rules (e.g., different package structures), make your rules configurable in the shared library. For example:

public class DropwizardArchitectureEnforcer {
    // Reusable rule with configurable package prefix
    public static ArchRule resources_must_extend_managed_resource(String basePackage) {
        return classes().that().resideInAPackage(basePackage + "..resource..")
            .should().beAssignableTo(ManagedResource.class);
    }
}

Then call this from a service’s test class to tailor the rule to its specific structure:

@ArchTest
public static final ArchRule custom_resource_rule = 
    DropwizardArchitectureEnforcer.resources_must_extend_managed_resource("com.my.unique.service");

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