A Java architecture test library, to specify and assert architecture rules in plain Java

Related tags

Testing ArchUnit
Overview

CI Maven Central License

ArchUnit

ArchUnit is a free, simple and extensible library for checking the architecture of your Java code. That is, ArchUnit can check dependencies between packages and classes, layers and slices, check for cyclic dependencies and more. It does so by analyzing given Java bytecode, importing all classes into a Java code structure. ArchUnit's main focus is to automatically test architecture and coding rules, using any plain Java unit testing framework.

An Example

Add the Maven Central dependency to your project

Gradle
testImplementation 'com.tngtech.archunit:archunit:0.17.0'
Maven
<dependency>
    <groupId>com.tngtech.archunit</groupId>
    <artifactId>archunit</artifactId>
    <version>0.17.0</version>
    <scope>test</scope>
</dependency>

Create a test

import com.tngtech.archunit.core.domain.JavaClasses;
import com.tngtech.archunit.core.importer.ClassFileImporter;
import com.tngtech.archunit.lang.ArchRule;

import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.classes;

public class MyArchitectureTest {
    @Test
    public void some_architecture_rule() {
        JavaClasses importedClasses = new ClassFileImporter().importPackages("com.myapp");
    
        ArchRule rule = classes()... // see next section
    
        rule.check(importedClasses);
    }
}

Let the API guide you

ArchUnit Fluent API

Where to look next

For further information, check out the user guide at http://archunit.org or test examples for the current release at ArchUnit Examples.

License

ArchUnit is published under the Apache License 2.0, see http://www.apache.org/licenses/LICENSE-2.0 for details.

It redistributes some third party libraries:

All licenses for ArchUnit and redistributed libraries can be found within the licenses folder.

Comments
  • Test fails on Windows

    Test fails on Windows

    It seems this commit should have fixed the issue - but they still fail on Windows: https://github.com/TNG/ArchUnit/commit/b040d90a987e6e032bc0534ea5e7efdbfe1e1c53

    On Mac/Linux everything is fine.

    opened by callmeberzerker 44
  • ArchCondition to ensure no upper package access incl. solution

    ArchCondition to ensure no upper package access incl. solution

    Hie there, would be great to have the following ArchCondition available out of the box like noClasses().should().accessClassesThat().resideInAnUpperPackage().check(classes); however I was not able to create a PR for this, so please feel free to just assimilate my solution below :-D

    import static java.lang.String.format;
    import static java.lang.System.lineSeparator;
    import static java.util.stream.Collectors.toList;
    
    import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.noClasses;
    
    import java.util.List;
    
    import org.junit.jupiter.api.Test;
    
    import com.tngtech.archunit.core.domain.Dependency;
    import com.tngtech.archunit.core.domain.JavaClass;
    import com.tngtech.archunit.core.domain.JavaClasses;
    import com.tngtech.archunit.core.importer.ClassFileImporter;
    import com.tngtech.archunit.core.importer.ImportOption;
    import com.tngtech.archunit.lang.ArchCondition;
    import com.tngtech.archunit.lang.ConditionEvents;
    import com.tngtech.archunit.lang.SimpleConditionEvent;
    
    public class ArchitectureTest {
    
        private final JavaClasses classes = new ClassFileImporter()
                .withImportOption(ImportOption.Predefined.DONT_INCLUDE_TESTS)
                .importPackages("foo.project.root.package");
    
       @Test
        public void ensureNoClassesAccessClassesThatResideInAnUpperPackage() {
            noClasses().should(accessClassesThatResideInAnUpperPackage()).check(classes);
            // requested solution
            // noClasses().should().accessClassesThat().resideInAnUpperPackage().check(classes);
        }
    
        private ArchCondition<JavaClass> accessClassesThatResideInAnUpperPackage(){
            return new ArchCondition<>("access upper packages") {
                @Override
                public void check(final JavaClass clazz, final ConditionEvents events) {
                    final List<Dependency> dependenciesThatResideInAnUpperPackage = clazz.getDirectDependenciesFromSelf().stream()
                            .filter(it -> !it.getTargetClass().getPackageName().isEmpty())
                            .filter(it -> !clazz.getPackageName().equals(it.getTargetClass().getPackageName()))
                            .filter(it -> clazz.getPackageName().startsWith(it.getTargetClass().getPackageName()))
                            .collect(toList());
    
                    final boolean satisfied = !dependenciesThatResideInAnUpperPackage.isEmpty();
    
                    final StringBuilder messageBuilder = new StringBuilder(format("%s to upper package found within class %s",
                            satisfied ? "Access" : "No access",
                            clazz.getName()));
                    for (Dependency dependency : dependenciesThatResideInAnUpperPackage) {
                        messageBuilder.append(lineSeparator()).append(dependency.getDescription());
                    }
    
                    events.add(new SimpleConditionEvent(clazz, satisfied, messageBuilder.toString()));
                }
            };
        }
    }
    
    opened by qoomon 25
  • Dependencies should consider annotations

    Dependencies should consider annotations

    At the moment JavaClass.getDirectDependenciesFromSelf() and JavaClass.getDirectDependenciesToSelf() don't consider annotations. Annotations (and their parameters) should be considered dependencies as well. This includes

    • all annotations on the JavaClass or any JavaMember of that class
    • all JavaClass parameters of those annotations
    • all JavaClass parameters of annotations within those annotations (and transitively their annotations and so on)

    E.g.

    @OnClass
    @InAnnotation(
        type = AnotherDependency.class,
        nested = @InNestedAnnotation(type = YetAnotherDependency.class)
    )
    class SomeClass {
        @OnField
        Object field;
    
        @OnConstructor
        SomeClass() {}
    
        @OnMethod
        void method() {
        }
    }
    

    Then OnClass, InAnnotation, AnotherDependency, InNestedAnnotation, YetAnotherDependency, OnField, OnConstructor and OnMethod should all be returned as direct dependencies of SomeClass.

    enhancement help wanted good start to contributing 
    opened by codecholeric 23
  • Add

    Add "onion architecture" builder

    As discussed in #89, we added the OnionArchitecture class. It is based on the LayeredArchitecture class and dynamically creates the corresponding layers so that the user only needs to define the layers but not take care of the wiring. A proposed example usage looks as follows (copied from https://github.com/TNG/ArchUnit/pull/174/commits/1aaab34bf820886c91d064c34d51bb98f8a36f9f#diff-55f996d59802ba953c99c1e0199b6a85R158).

    OnionArchitecture architecture = onionArchitecture()
            .domainModel("com.tngtech.archunit.library.testclasses.onionarchitecture.domain.model")
            .domainService("com.tngtech.archunit.library.testclasses.onionarchitecture.domain.service")
            .application("com.tngtech.archunit.library.testclasses.onionarchitecture.application")
            .adapter("cli", "com.tngtech.archunit.library.testclasses.onionarchitecture.adapter.cli")
            .adapter("persistence", "com.tngtech.archunit.library.testclasses.onionarchitecture.adapter.persistence")
            .adapter("rest", "com.tngtech.archunit.library.testclasses.onionarchitecture.adapter.rest");
    

    In particular, the usage of multiple .adapter calls allows to define the adapters that should be kept independent from each other in a very generic way. One could, for instance, decide that no adapter is allowed to access another one (see the above example), or that all adapters can share code (by using only a single .adapter call).

    Let us know if the builder looks as expected. If yes, we will add the missing documentation.

    opened by spanierm42 22
  • Record Method Calls to the same Class

    Record Method Calls to the same Class

    I want to create an ArchRule to make sure that methods annotated with Spring's @Async annotation are not called from the same class.

    (These methods should not be called from the same class because Spring needs to create a proxy to make @Async work.)

    So I made this rule:

        @ArchTest
        public static final ArchRule asyncMethodsShouldNotBeCalledFromTheSameInstance = noClasses()
                .should()
                .callMethodWhere(DescribedPredicate.describe("no async from same class", input ->
                        {
                            return input.getTarget().isAnnotatedWith(Async.class) &&
                                    input.getOriginOwner().equals(input.getTargetOwner());
                        }
                ))
                .as("@Async Methods should never be called from the same class because no proxy can be used then.");
    

    Unfortunately, this does not work because apparently method calls to the same class do not seem to be collected. Is there any way I can configure this?

    enhancement 
    opened by waschmittel 18
  • FreezingArchRule breaks when executed from IDE and maven

    FreezingArchRule breaks when executed from IDE and maven

    Environment:

    • JDK11

    Expected behavior: When the store files are generated, the tests should all pass independent of the test execution (here: IntelliJ or maven)

    Actual behavior:

    • When the store files were generated through IntelliJ, the tests only pass when they are executed through IntelliJ. Executing the tests through maven will result in test failures.
    • When the store files were generated through maven, the tests only pass when they are executed through maven. Executing the tests through IntelliJ will result in test failures.

    How to reproduce:

    • Check out this PR: https://github.com/Taskana/taskana/pull/1971 where we've enabled our architecture tests (store files were generated through IntelliJ)
    • Execute the ArchitectureTest class through IntelliJ. All tests should pass.
    • Execute the ArchitectureTest class through maven. Some tests should fail. Execution command (from project root directory):
    #build dependencies
    ./mvnw clean install -pl :taskana-core-test -am -DskipTests
    #execute tests from ArchitectureTest class
    ./mvnw clean verify -pl :taskana-core-test -Dtest="ArchitectureTest"
    

    Further notes:

    As of right now we've disabled the tests, since this behavior is blocking us. You can find our test class here: https://github.com/Taskana/taskana/blob/master/lib/taskana-core-test/src/test/java/acceptance/ArchitectureTest.java The tests packagesShouldBeFreeOfCyclicDependencies and classesShouldBeFreeOfCyclicDependencies will fail. We've already set the following properties to an unreasonable high amount in order to make sure that all errors are detected.

    cycles.maxNumberToDetect=100000
    cycles.maxNumberOfDependenciesPerEdge=10000
    

    During our initial debugging we've found out that the line numbers differ between the execution through maven and IntelliJ. Furthermore we've seen that IntelliJ and maven name lambda's differently, which is a second difference in the store files.

    Screenshot from 2022-07-18 16-18-53 Screenshot from 2022-07-18 16-18-30

    opened by mustaphazorgati 16
  • Meta-annotations are not discovered

    Meta-annotations are not discovered

    Hi,

    I have an issue with meta-annotations:

    Finder.java

    import org.springframework.stereotype.Component;
    import org.springframework.transaction.annotation.Transactional;
    
    import java.lang.annotation.Documented;
    import java.lang.annotation.ElementType;
    import java.lang.annotation.Inherited;
    import java.lang.annotation.Retention;
    import java.lang.annotation.RetentionPolicy;
    import java.lang.annotation.Target;
    
    @Target(ElementType.TYPE)
    @Component
    @Transactional(readOnly = true)
    @Retention(RetentionPolicy.RUNTIME)
    @Inherited
    @Documented
    public @interface Finder {
    }
    

    MyFinder.java

    import org.springframework.transaction.annotation.Transactional;
    
    @Finder
    public class MyFinder {
    }
    

    ArchitectureTest.java

    import com.tngtech.archunit.core.importer.ImportOption;
    import com.tngtech.archunit.junit.AnalyzeClasses;
    import com.tngtech.archunit.junit.ArchRules;
    import com.tngtech.archunit.junit.ArchTest;
    import com.tngtech.archunit.lang.ArchRule;
    import DDDArchTests;
    
    @AnalyzeClasses(packagesOf = ArchitectureTest.class,
                    importOptions = {
                            ImportOption.DoNotIncludeArchives.class,
                            ImportOption.DoNotIncludeTests.class
                    }
    )
    class ArchitectureTest {
    
        @ArchTest
        public static final ArchRules dddTests = ArchRules.in(DDDArchTests.class);
    }
    

    DDDArchTests.java

    import com.tngtech.archunit.junit.ArchTest;
    import com.tngtech.archunit.lang.ArchRule;
    import lombok.AccessLevel;
    import lombok.NoArgsConstructor;
    import org.springframework.transaction.annotation.Transactional;
    
    import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.classes;
    import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.methods;
    
    @NoArgsConstructor(access = AccessLevel.PRIVATE)
    public final class DDDArchTests {
    
    ...
        @ArchTest
        public static final ArchRule rule =
                classes().that().areAnnotatedWith(Finder.class)
                        .should().beMetaAnnotatedWith(Transactional.class);
    ...
    

    I expect that this rule doesn't fail BUT: Rule 'classes that are annotated with @Finder should be meta-annotated with @Transactional' was violated ... Class <...MyFinder> is not meta-annotated with @Transactional in (MyFinder.java:0)

    Is it a bug or I misunderstand the API?

    P.S. I tried to debug it a bit and I could also see that such annotations like Spring's @Configuration don't contain information that they annotated with @Component annotation.

    enhancement help wanted 
    opened by vprudnikov 16
  • Support Java 16-ea

    Support Java 16-ea

    Follow-up from #230

    Using ArchUnit with Java 16-ea the following warning is produced:

    WARN  com.tngtech.archunit.core.importer.ClassFileProcessor - Error during import from jrt:/java.base/java/lang/Double.class, falling back to simple import
    2020-08-09T08:53:33.8837041Z java.lang.IllegalArgumentException: Unsupported class file major version 60
    2020-08-09T08:53:33.8841068Z 	at com.tngtech.archunit.thirdparty.org.objectweb.asm.ClassReader.<init>(ClassReader.java:196) ~[archunit-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8845990Z 	at com.tngtech.archunit.thirdparty.org.objectweb.asm.ClassReader.<init>(ClassReader.java:177) ~[archunit-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8849712Z 	at com.tngtech.archunit.thirdparty.org.objectweb.asm.ClassReader.<init>(ClassReader.java:163) ~[archunit-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8853743Z 	at com.tngtech.archunit.thirdparty.org.objectweb.asm.ClassReader.<init>(ClassReader.java:284) ~[archunit-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8857894Z 	at com.tngtech.archunit.core.importer.ClassFileProcessor$UriImporterOfProcessor.tryImport(ClassFileProcessor.java:186) ~[archunit-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8863460Z 	at com.tngtech.archunit.core.importer.resolvers.ClassResolverFromClasspath.tryResolve(ClassResolverFromClasspath.java:51) ~[archunit-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8868778Z 	at com.tngtech.archunit.core.importer.ImportedClasses.ensurePresent(ImportedClasses.java:60) ~[archunit-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8873732Z 	at com.tngtech.archunit.core.importer.ClassGraphCreator.ensureCallTargetsArePresent(ClassGraphCreator.java:116) ~[archunit-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8877964Z 	at com.tngtech.archunit.core.importer.ClassGraphCreator.complete(ClassGraphCreator.java:98) ~[archunit-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8882517Z 	at com.tngtech.archunit.core.importer.ClassFileProcessor.process(ClassFileProcessor.java:62) ~[archunit-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8889662Z 	at com.tngtech.archunit.core.importer.ClassFileImporter.importLocations(ClassFileImporter.java:336) ~[archunit-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8897044Z 	at com.tngtech.archunit.junit.ClassCache$CacheClassFileImporter.importClasses(ClassCache.java:121) ~[archunit-junit5-engine-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8936872Z 	at com.tngtech.archunit.junit.ClassCache$LazyJavaClasses.initialize(ClassCache.java:113) ~[archunit-junit5-engine-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8937872Z 	at com.tngtech.archunit.junit.ClassCache$LazyJavaClasses.get(ClassCache.java:102) ~[archunit-junit5-engine-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8938572Z 	at com.tngtech.archunit.junit.ClassCache.getClassesToAnalyzeFor(ClassCache.java:79) ~[archunit-junit5-engine-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8946068Z 	at com.tngtech.archunit.junit.ArchUnitTestDescriptor.lambda$createChildren$1(ArchUnitTestDescriptor.java:82) ~[archunit-junit5-engine-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8946618Z 	at com.tngtech.archunit.thirdparty.com.google.common.base.Suppliers$MemoizingSupplier.get(Suppliers.java:120) ~[archunit-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8947155Z 	at com.tngtech.archunit.junit.ArchUnitTestDescriptor$ArchUnitRuleDescriptor.execute(ArchUnitTestDescriptor.java:159) ~[archunit-junit5-engine-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8947688Z 	at com.tngtech.archunit.junit.ArchUnitTestDescriptor$ArchUnitRuleDescriptor.execute(ArchUnitTestDescriptor.java:142) ~[archunit-junit5-engine-0.14.1.jar:0.14.1]
    2020-08-09T08:53:33.8948218Z 	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:139) ~[junit-platform-engine-1.7.0-SNAPSHOT.jar:1.7.0-SNAPSHOT]
    

    https://github.com/junit-team/junit5/runs/963324482#step:7:678

    An upgrade of the shadowed ASM library to version 9.0 beta should prevent this warning being emitted.

    opened by sormuras 15
  • ArchUnit needs better (user) documentation

    ArchUnit needs better (user) documentation

    when compared to jQAssist, ArchUnit has some way to go wrt user documentation and accessibility.

    Simple proposal: setup a static site generator (e.g. jekyll): You might copy the configuration/setup from arc42.org and simply replace the content... (there's already a dockerized version so you don't need to install jekyll, ruby etc.).

    In case of questions with this setup, I'm happy to support...

    opened by gernotstarke 14
  • Feature/make arbitrary arch conditions from predicates

    Feature/make arbitrary arch conditions from predicates

    This is a partial fix for #855.

    I've added two of the methods with some tests. A couple of points though:

    a) I had severe problems, getting this to build (see #437) and test (in IntelliJ lots of tests are executed even if only a few are selected). So formatting might be off

    b) I have adapted one architecture check - my reasoning is that just converting from a DescribedPredicate<T> to a ArchCondition<T> is ok without contravariance. It makes stuff easier to diagnose and doesn't loose any power as ArchConditions are already handled contravariantly.

    c) I have also added an 'inverse' test but I cannot get that to fail - beats me why.

    I'm looking forward to your feedback!

    opened by u3r 13
  • Load classes from TCCL

    Load classes from TCCL

    This allows ArchUnit to work with Quarkus continuous testing, which does not have a flat class path.

    Quarkus continuous testing runs tests repeatedly in the same VM when class files are changed, which means that the tests need to be loaded in a new ClassLoader every time (which is set to the Thread context ClassLoader). Without this patch ArchUnit cannot load the classes.

    Signed-off-by: Stuart Douglas [email protected]

    opened by stuartwdouglas 13
  • Bump com.diffplug.spotless from 6.12.0 to 6.12.1

    Bump com.diffplug.spotless from 6.12.0 to 6.12.1

    Bumps com.diffplug.spotless from 6.12.0 to 6.12.1.

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies java 
    opened by dependabot[bot] 0
  • Analyze a path with @AnalyzeClasses

    Analyze a path with @AnalyzeClasses

    The ClassFileImporter offers the method "importPath()" to import classes in a specific path instead of a specific package. Is there an equivalent for @AnalyzeClasses? Something like

    @AnalyzeClasses(path = "src/main")
    

    Our project uses a lof of generated code that uses the same package structure as non-generated code and we would like to exclude the generated code from being scanned.

    opened by TheConen 1
  • [suggestion] add test name to frozen violation guid files

    [suggestion] add test name to frozen violation guid files

    Hi, congrats on this project, really helping us in our development efforts.

    We've recently started using the freezing violations feature, and while it works well, it would be useful for us if the guid files could contain, perhaps as a comment on the first line, the name of the rule that is being violated.

    For example, in stored.rules I have:

    classes\ that\ are\ annotated\ with\ @PersistenceCapable\ and\ not\ a\ rolled\ up\ subclass\ should\ be\ annotated\ with\ @PersistenceCapable(schema\=...)=37b32699-a3f3-42fa-b86a-22bc2d89ec18
    

    and in 37b32699-a3f3-42fa-b86a-22bc2d89ec18 I have the two violations for my unit tests of the arch tests (to make sure that they are correctly detecting violations):

    Class <org.estatio.base.test.archtests.rules.persistencecapable.pcschema.PersistenceCapableWithoutSchema> is not annotated with @PersistenceCapable(schema=...) in (PersistenceCapableWithoutSchema.java:0)
    Class <org.estatio.base.test.archtests.rules.persistencecapable.pcschema.PersistenceCapableWithoutSchemaButIsRolledUpSuperclass> is not annotated with @PersistenceCapable(schema=...) in (PersistenceCapableWithoutSchemaButIsRolledUpSuperclass.java:0)
    

    What I'm looking for is simply that the guid file looks something like:

    #classes\ that\ are\ annotated\ with\ @PersistenceCapable\ and\ not\ a\ rolled\ up\ subclass\ should\ be\ annotated\ with\ @PersistenceCapable(schema\=...)
    Class <org.estatio.base.test.archtests.rules.persistencecapable.pcschema.PersistenceCapableWithoutSchema> is not annotated with @PersistenceCapable(schema=...) in (PersistenceCapableWithoutSchema.java:0)
    Class <org.estatio.base.test.archtests.rules.persistencecapable.pcschema.PersistenceCapableWithoutSchemaButIsRolledUpSuperclass> is not annotated with @PersistenceCapable(schema=...) in (PersistenceCapableWithoutSchemaButIsRolledUpSuperclass.java:0)
    

    in other words line 1 lists the rule being violated.

    opened by danhaywood 3
  • Bump actions/setup-java from 3.8.0 to 3.9.0

    Bump actions/setup-java from 3.8.0 to 3.9.0

    Bumps actions/setup-java from 3.8.0 to 3.9.0.

    Release notes

    Sourced from actions/setup-java's releases.

    v3.9.0

    In scope of this release we add support for .java-version file (actions/setup-java#426). For more information about its usage please refer to the documentation.

        steps:
          - uses: actions/checkout@v3
          - name: Setup java
            uses: actions/setup-java@v3
            with:
              distribution: '<distribution>'
              java-version-file: .java-version
          - run: java HelloWorldApp.java
    
    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies github_actions 
    opened by dependabot[bot] 0
  • Bump com.gradle.enterprise from 3.11.4 to 3.12

    Bump com.gradle.enterprise from 3.11.4 to 3.12

    Bumps com.gradle.enterprise from 3.11.4 to 3.12.

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies java 
    opened by dependabot[bot] 1
Releases(v1.0.1)
  • v1.0.1(Nov 21, 2022)

    Bug Fixes

    • Fix bug where referenced class objects and instanceof checks were not detected if declared within a lambda (see #992)
    • Fix empty records not being detected as records (see #998; thanks a lot to @hankem)
    • Fix Javadoc on layeredArchitecture() missing the new consideringDependencies part (see #977; thanks a lot to @Thunderforge)
    • Fix user guide still showing DescribedPredicate.apply instead of .test (see #978; thanks a lot to @thmuch)
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0(Oct 3, 2022)

    :warning: If you upgrade from the latest 0.x version, please also refer to the release notes of release candidate 1.0.0-rc1 as these release notes refer to upgrading from the release candidate :warning:

    Breaking Changes

    • Naming around JavaPackage subpackages and dependencies has been improved to remove ambiguities. In general, whenever all classes from a package and subpackages recursively are involved, this is now called "package tree". Otherwise, it only targets the classes directly within this package (see #919/#968; thanks a lot to @grimsa) The following mapping shows how to translate the old methods to the current methods:
      • getAllClasses() -> getClassesInPackageTree()
      • getAllSubpackages() -> getSubpackagesInTree()
      • getClassDependenciesFromSelf() -> getClassDependenciesFromThisPackageTree()
      • getClassDependenciesToSelf() -> getClassDependenciesToThisPackageTree()
      • getPackageDependenciesFromSelf() -> getPackageDependenciesFromThisPackageTree()
      • getPackageDependenciesToSelf() -> getPackageDependenciesToThisPackageTree()
      • accept(..) -> traversePackageTree(..)
    • Importing the default package via ClassFileImporter.importPackages("") will now yields the same result as using importClasspath() without any ImportOption (see #954)
    • ClassFileImporter.importClasspath() now behaves consistently to other import APIs. I.e. no default ImportOptions like DoNotIncludeArchives are added anymore, instead all ImportOptions need to be added the same way as for all other import methods (see #958)
    • The custom collection ImportOptions has been removed from the public API and been replaced by a standard Collection<ImportOption> where appropriate (see #958)
    • The package com.tngtech.archunit.library.plantuml has been moved to com.tngtech.archunit.library.plantuml.rules to make room for adding other PlantUML related features (see #959)
    • SLF4J-API has been upgraded from 1.7.30 to 2.0.3, so any log adapter dependency to be used with ArchUnit (e.g. to hook in Log4J) has to be compatible with SLF4J-API 2.x from now on (see #966)

    Bug Fixes

    • Fix bug where multiple synthetic access calls to methods like access$123(..) would lead to only one access being imported. Note, that these synthetic methods are added for calls to private fields / methods from inner classes to outer classes, etc. (see #957)

    Enhancements

    Lang

    • archunit_ignore_patterns.txt is now also respected by FreezingArchRule. Thus, ignored violations are not added to the ViolationStore anymore (see #915)

    Library

    • testClassesShouldResideInTheSamePackageAsImplementation(..) now supports multiple test classes with same simple name (see #918; thanks a lot to @mslowiak)
    • PlantUmlArchCondition now does not throw exceptions anymore, if a class is in none or multiple components, but instead reports those as standard violations. This way these violations can also be frozen via FreezingArchRule instead of crashing the test (see #960)

    Further Acknowledgement

    • Thanks a lot to @hankem for upgrading various dependencies, cleaning up code and extensive reviews
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0-rc1(Jul 13, 2022)

    Breaking Changes

    • All deprecated members and classes have been removed (see #909)
    • @AnalyzeClasses() without any explicit locations to import will now import the package of the annotated class by default instead of the whole classpath. To restore the old behavior use @AnalyzeClasses(wholeClasspath = true) (see #828)
    • The archunit-junit5-engine-api now resides within the package com.tngtech.archunit.junit.engine_api instead of directly under junit. This only affects users that want to programmatically interface with the ArchUnitTestEngine and should be irrelevant for most users (see #827)
    • ArchUnit now needs at least Java 8 to run (see #833)
    • The ArchUnit types Function, Predicate and Optional have been replaced by the JDK 8 equivalents
    • DescribedPredicate now extends the JDK 8 Predicate, so apply(..) has to be replaced by test(..)
    • layeredArchitecture() now forces to decide how to deal with dependencies by adding .considering...Dependencies() in the beginning of the declaration. To restore the old behavior declare it as layeredArchitecture().consideringAllDependencies() (see #892)
    • ConditionEvents is now an interface and the interface has been cleaned out of all non-essential methods, e.g. getAllowed(). This was done to increase maintainability and make it easier to optimize the internals. If you are missing any functionality now, please file an issue to discuss it (see #876)
    • PackageMatcher was moved from package base to core.domain (see #894)
    • Primitive classes now reside in package java.lang to be consistent with the Reflection API's Class.getPackageName() (see #905)
    • PlantUmlArchCondition.Configurations has been merged into PlantUmlArchCondition.Configuration (see #891)

    Bug Fixes

    • While technically no real bug PlantUmlArchCondition.Configuration is now a public class instead of an interface, which solves a (non-fatal) Kotlin compiler warning complaining about the access rights (see #888)

    Enhancements

    Core

    • Accesses from inside of lambdas are now correctly detected. Before, the origin was set as a synthetic method like lambda$xxx$123 instead. JavaAccess can now be queried for isDeclaredInLambda() to distinguish this from an access outside of a lambda (see #847; thanks a lot to @oberprah, @FrederikFinckh)
    • Support for Java 19 (see #845)
    • It is now possible to analyze try-catch-blocks, e.g. if a method call is wrapped into a try-catch-block catching a certain exception type (see #591; thanks a lot to @crizzis)
    • Package identifiers like ..myapp.service.. now support alternations via ..[service|legacy_service]... This also works for capturing groups like (a|b). Note that alternation groups cannot be nested (see #662; thanks a lot to @Pfoerd)
    • DescribedPredicate now offers static factory methods and(predicates) and or(predicates) that join together varargs DescribedPredicate<>... or Iterable<DescribedPredicate<>> via AND or OR (see #805)
    • The importer now ignores synthetic $SwitchMap$ fields of enums (see #570)
    • Private member accesses are now correctly reported between inner classes. Before, the origin was set as a synthetic method access$123 (see #889)
    • ImportOption.DoNotIncludeTests now works for plain IntelliJ project layouts (see #696; thanks a lot to @JCook21)

    Lang

    • New methods codeUnits().should().onlyBeCalled().by{Classes/Methods/...}That(..) (see #810; thanks a lot to @JKLedzion)
    • ArchCondition evaluation is now more efficient and has a smaller memory footprint (see #876)
    • The ArchCondition to search for transitive dependencies has been improved and now only reports relevant dependencies, in particular when checking for transitive dependencies between packages a and b (see #780; thanks a lot to @Pfoerd)
    • New APIs ArchCondition.from(predicate) and ArchConditions.{be/have}(predicate) to easily create ArchConditions from DescribedPredicates (see #855; thanks a lot to @u3r)
    • Javadoc of the rules API has been extended to better guide to predefined DescribedPredicates like JavaClass.Predicates or HasName.Predicates (see #912)
    • New convenience method ConditionEvent.createMessage(..) to easily create a standard ArchRule violation message like Class <..> some description in (...java:123) (see #826)

    Library

    • layeredArchitecture() now allows to easily specify how to deal with dependencies from classes within the layers. E.g. should only dependencies that target other classes within the layers be considered? Or all dependencies in the root package of the application? This should solve common confusion about dependencies on classes like java.lang.Object being reported (see #887)
    • onionArchitecture() components can now not only be defined by package identifiers but also by predicates (see #894)
    • layeredArchitecture() and onionArchitecture() now support ensureAllClassesAreContainedInArchitecture() (see #278; thanks a lot to @roxspring)
    • New rule GeneralCodingRules.testClassesShouldResideInTheSamePackageAsImplementation() to check that test classes reside in the same package as their class under test (see #475; thanks a lot to @mslowiak)

    JUnit

    • The archunit-junit5 can now be used on the modulepath as well as the classpath (see #206)
    • JUnit 5 discovery speed is now notably faster in test projects with a lot of dependencies (see #546)
    • For JUnit 5 support @ArchTest is now also supported within abstract base classes (see #104; thanks a lot to @hankem)

    Further Acknowledgement

    • thanks a lot to @marknp for migrating the code base to JDK 8 (see #833)
    • thanks a lot to @grimsa for improving the Javadoc on JavaClass.Predicates (see #814)
    • thanks a lot to @rweisleder for Javadoc improvements regarding annotation APIs (see #835)
    • thanks a lot for various reviews to @hankem, @spanierm42, @kaebiscs, @KorSin, @GandalfIX
    Source code(tar.gz)
    Source code(zip)
  • v0.23.1(Feb 27, 2022)

    Bug Fixes

    • Fix exception Never found a JavaCodeUnit that matches supposed origin... occurring with Kotlin inline functions where the descriptor of a method deviates from the signature (this was introduced by checking the return type of the method as well when looking for a call origin in #714; see #804, #807)
    • Fix optional layers of LayeredArchitecture failing with the new default behavior archRule.failOnEmptyShould = true (see #809; thanks a lot to @oberprah)

    Enhancements

    • Log automatic resolution configuration on debug to reduce log clutter (see #802)
    • Add new Method ArchRule.allowEmptyShould(boolean) to override the configured archRule.failOnEmptyShould configuration on a per rule basis (see #803, #806, #808; thanks a lot to @oberprah)
    Source code(tar.gz)
    Source code(zip)
  • v0.23.0(Feb 20, 2022)

    Breaking Changes

    • As mentioned in Enhancements/Core ArchRules will now by default reject evaluating if the set passed to the should-clause is empty. This will break existing rules that don't check any elements in their should-clause. You can restore the old behavior by setting the ArchUnit property archRule.failOnEmptyShould=false

    Bug Fixes

    • Fix wrong origins of JavaCall in case of bridge methods. If a class had two methods with the exact same name and parameter types the origin of a JavaCall was picked randomly from them. It now always picks the non-synthetic method (see #513)
    • Fix non-deterministic return value of JavaCodeUnit.getMethod(). In case of bridge methods there might be more than one method matching the exact same name and parameters. In these cases the result of getMethod() was random. It now always picks the non-synthetic method (see #256)
    • layeredArchitecture() will now allow to combine mayOnlyBeAccessedBy... and mayOnlyAccess.... Previously mayOnlyAccess... would forbid all incoming dependencies (see #739; thanks a lot to @hankem)

    Enhancements

    Core

    • Members targeted by AccessTarget are now resolved like the Java Reflection API would do it. Previously AccessTarget.resolve() would return a set of matching members, the new replacement AccessTarget.resolveMember() returns an optional member making it a lot easier to handle (see #722)
    • JavaClass now knows its methodReferencesFromSelf (e.g. Object::toString) and constructorReferencesFromSelf (e.g. Object::new) (see #215; thanks a lot to @KorSin)
    • ArchRules will now by default reject evaluating if the set passed to the should-clause is empty. This prevents implementation errors like picking a package in that()... that doesn't even exist and thus composing a rule that doesn't check anything (compare the user guide; see #774; thanks a lot @oberprah)
    • The automatic import dependency resolution now resolves classes missing from the import that are only referenced
      • as class object (e.g. Foo.class)
      • in a throws clause (e.g. someMethod() throws FooException)
      • in an instanceof check (e.g. obj instanceof Foo)
      • as an array component type (e.g. Foo[] array;)
      • as an annotation parameter (e.g. @SomeAnnotation(type = Foo.class))
      • as part of a generic type signature (e.g. List<? extends Foo>)
      • Furthermore, the resolution behavior can now be tweaked to resolve deeper or not resolve at all. Thus, users can decide between resolving additional types and performance (compare the user guide; see #728)
    • New predefined ImportOption to exclude package-info.class files (see #793; thanks a lot to @TomerFi)

    Lang

    • Analogously to classes(), there now exists a method members()...should().containNumberOfElements(predicate) (see #179; thanks a lot to @oberprah)

    Library

    • PlantUmlArchCondition now rejects files that don't specify any components at all or are of an invalid format (see #735; thanks a lot to @pfichtner)

    JUnit

    • Tests can now be run if their classes are loaded by the context ClassLoader instead of the ArchUnit ClassLoader (see #781; thanks a lot to @stuartwdouglas)
    • New method Class<?> FieldSource.getJavaClass() to retrieve the declaring class of the respective field (see #800; thanks a lot to @famod)

    Further Acknowledgement

    • thanks a lot to @marknp for improving the Javadoc on ArchConditions (see #725)
    • thanks a lot to @timtebeek for making the ArchUnit build work with JDK 17 (see #779)
    Source code(tar.gz)
    Source code(zip)
  • v0.22.0(Oct 30, 2021)

    Bug Fixes

    • Java class file URLs with spaces are now correctly handled when resolving transitive dependencies (see #683)
    • fixed memory leak in ArchUnit JUnit 5 support (see #695)
    • three bug fixes regarding generics import (see #700)
      • toplevel generic array types (e.g. T[]) were not detected correctly as method parameters
      • primitive types were missing from the generic JavaCodeUnit.getParameterTypes()
      • inner classes were not detected correctly as upper bounds of type parameters

    Enhancements

    Core

    • support for method and constructor parameter annotations (see #701; thanks a lot to @hankem for extensive reviews)
      • new method JavaCodeUnit.getParameters() that will return parameters in a structured form offering raw type, generic type and annotations
      • new method JavaCodeUnit.getParameterAnnotations() that offers just parameter annotations by index
      • parameter annotations are now part of JavaClass.directDependencies{from/to}Self
    • SourceCodeLocation now offers structured access to source file and source class (see #673; thanks a lot to @thmuch)

    JUnit

    • new option to replace underscores in rule field/method names by spaces in the test description to improve readability (see #626; thanks a lot to @thmuch)
    Source code(tar.gz)
    Source code(zip)
  • v0.21.0(Aug 22, 2021)

    Breaking Changes

    • the type JavaClassList has been removed completely. It was used inconsistently and provided very limited value (convenient way to get the names of the classes). On the other hand having a custom list implementation increases maintenance overhead and limits options in the future. Please replace usages of JavaClassList.getNames() by the static utility HasName.Utils.namesOf(classes) which can be used on any Iterable with elements of type HasName (see #633)

    Enhancements

    Core

    • JavaMethod now knows its generic parameter types (retrievable via JavaMethod.getParameterTypes()). Furthermore type arguments of generic method parameter types are now part of the JavaClass.directDependencies{From/To}Self (see #640)

    Library

    • the PlantUML rule syntax now allows colored components (see #258; thanks a lot to @johthor)

    Further Acknowledgement

    • thanks a lot to @NilsOliverLinden for further automating the release process (see #646)
    Source code(tar.gz)
    Source code(zip)
  • v0.20.1(Jul 16, 2021)

    Bug Fixes

    • Fix bug where some anonymous classes compiled with JDK 7 could not be imported anymore (java.lang.IllegalArgumentException: Can't register multiple enclosing classes, this is likely a bug!) (see #637)
    Source code(tar.gz)
    Source code(zip)
  • v0.20.0(Jul 4, 2021)

    Bug Fixes

    • onionArchitecture() no longer loses ignored dependencies, if the description is changed afterwards (see #623; thanks a lot to @thmuch)

    Enhancements

    Core

    • added support for JDK 18 (see #625; thanks a lot to @hankem)
    • new method JavaCodeUnit.getTypeParameters(). Also the bounds of these type parameters have been added to JavaClass.directDependencies{From/To}Self (see #616; thanks a lot to @hankem for extensive reviews)
    • JavaMethod now knows its generic return type (retrievable via JavaMethod.getReturnType()). Furthermore type arguments of generic method return types are now part of the JavaClass.directDependencies{From/To}Self (see #616; thanks a lot to @hankem for extensive reviews)

    JUnit

    • upgraded JUnit Platform dependency from 1.7.1 to 1.7.2 (see #628)
    Source code(tar.gz)
    Source code(zip)
  • v0.19.0(May 30, 2021)

    Bug Fixes

    • The last release archive contained a couple of classes from dependencies that were not relocated and thus lead to duplicate classes warnings in some environments. These classes have been removed (see #593)

    Enhancements

    Core

    • JavaField now knows its generic type (retrievable via JavaField.getType()). Furthermore type arguments of generic field types are now part of the JavaClass.directDependencies{From/To}Self (see #595; thanks a lot to @hankem for extensive reviews)

    Lang

    • new method noClasses()...should().transitivelyDependOnClassesThat(..)... (see #575; thanks a lot to @hankem)
    • the failure descriptions of ArchRules can not be customized (see #343; thanks a lot to @Farbauti89)

    Library

    • new method layeredArchitecture()...mayOnlyAccessLayers(..)... (see #592; thanks a lot to @GiorgadzeLuka)
    • improved readability for cycle rule violations (see #369; thanks a lot to @jzheaux)
    • FreezingArchRule can now refreeze all violations, if current violations should simply be added to the ViolationStore without any failure (see #510)

    JUnit

    • annotations of test methods and fields are now passed to the TestDescription by the JUnit 4 test support (see #552)

    Further Acknowledgement

    • Thanks a lot to @GiorgadzeLuka and @OLibutzki for improving the documentation
    Source code(tar.gz)
    Source code(zip)
  • v0.18.0(Apr 14, 2021)

    Breaking Changes

    • JavaClass.get{All}Interfaces() is now JavaClass.get{All}RawInterfaces() to be consistent with regards to the generic JavaClass.getInterfaces(). We decided that this is still a less painful way than deprecating getInterfaces(), introducting a new getGenericInterfaces(), then deprecate getGenericInterfaces() in favor of getInterfaces() in a later release. To be consistent with other places in ArchUnit JavaClass.getInterfaces() needs to provide the generic version of the interfaces (compare e.g. JavaClass.getSuperclass()).

    Enhancements

    Core

    • Support for Java Records (see #295; thanks a lot to @rweisleder)
    • JavaClass now knows its generic interfaces (retrievable via JavaClass.getInterfaces()). Furthermore type arguments of generic interfaces are now part of the JavaClass.directDependencies{From/To}Self (see #551)

    Lang

    • New syntax methods classes().that().containAny{Members,Fields,Methods,...}That(..) (see #553; thanks a lot to @nils-christian)

    Library

    • Added an API to calculate Software Architecture Metrics inspired by John Lakos, Robert C. Martin and Herbert Dowalil. For further details check the user guide (see #572; thanks a lot to @hankem and @stefanhechtltng and to @hdowalil for the inspiration and support)

    Further Acknowledgement

    • Thanks a lot to @rweisleder and @Strohgelaender for improving the documentation
    Source code(tar.gz)
    Source code(zip)
  • v0.17.0(Feb 21, 2021)

    Breaking Changes

    • The metaAnnotatedWith(..) predicate, as well as all syntax elements like classes().that().areMetaAnnotatedWith(..) or classes().should().beMetaAnnotatedWith(..), now all also count direct annotations as matching. The background is, that the typical use case always seemed to be "either directly annotated or annotated with some meta-annotated annotation", so we decided to cover this directly.
      • If your rule has metaAnnotatedWith(..).or(annotatedWith(..)) it still works, but you can now drop the annotatedWith(..) part
      • If your rule really wanted to test that the annotation is not a direct annotation, but only meta-annotated on another annotation, this can still be asserted by metaAnnotatedWith(..).and(not(annotatedWith(..))) (see #527)

    Enhancements

    • Classes appearing in member signatures (like field types or method return values) are now automatically resolved in import (see #530)
    • Support for Java 17 (see #535)
    • New API to check if a JavaAnnotation has explicitly declared a certain property, i.e. it is set in the annotation and not taken from the default value (see #499)

    Lang

    • Improved Javadoc and error message to better explain the difference of classes().that().implement(..) and classes().that().areAssignableTo(..)

    Library

    • New rule to assert no proxy bypasses, e.g. if a Spring bean internally calls an @Async method and thus bypasses the proxy (see #539)

    JUnit

    • We decided to rename ArchRules.in(..) to ArchTests.in(..), because ArchRules was considered confusing, if the actual behavior is to collect all @ArchTest members of the other class. ArchRules is still present (yet deprecated), so this will not break existing ArchTest suites (see #525)
    Source code(tar.gz)
    Source code(zip)
  • v0.16.0(Jan 31, 2021)

    Bug Fixes

    • Fix modulepath issue where sometimes classes on the modulepath would not be imported correctly (see #497)
    • FreezingArchRule default violation store now works correctly cross-platform with regards to line separators (see #458, #508)

    Enhancements

    Core

    • JavaClass now knows its generic superclass (retrievable via JavaClass.getSuperclass()). Furthermore type arguments of generic superclasses are now part of the JavaClass.directDependencies{From/To}Self (see #503)
    • JavaClass/JavaCodeUnit now know their references to other class objects (e.g. Example in List.of(Example.class)). Furthermore class objects are now part of the JavaClass.directDependencies{From/To}Self (see #518)
    • Added new ImportOption.OnlyIncludeTests to execute ArchRules only on test classes (see #501; thanks a lot to @pstanoev)

    Further Acknowledgement

    • Thanks a lot to @rweisleder for improving the ArchUnit CI
    • Thanks a lot to @perlun for improving the Imprint
    • Thanks a lot to @sullis for upgrading the SLF4J dependency
    • Thanks a lot to @Bananeweizen for improving the user guide
    Source code(tar.gz)
    Source code(zip)
  • v0.15.0(Dec 16, 2020)

    Bug Fixes

    • TextFileBasedViolationStore now correctly handles empty violation store files (see #456; thanks a lot to @hankem)
    • Fix URL scheme part issue on Windows when reading classpath URLs from manifest files (see #414; thanks a lot to @eriklumme)

    Enhancements

    Core

    • Reduce excessive logging if archunit.properties are overwritten by system properties (see #375; thanks a lot to @ldebruijn)
    • New method JavaClass.tryGetConstructor() (see #386; thanks a lot to @rweisleder)
    • JavaClass now provides generic type information, i.e. there is now JavaClass.getTypeParameters() (see #398). Furthermore JavaClass now reports type parameter bounds as Dependencies (see #484)
    • JavaClass now offers JavaClass.getInstanceofChecks(), which are also reported as Dependencies (see #371; thanks a lot to @t-h-e)
    • Support for Java 15 and 16-ea (see #409)
    • Resolve imported annotations transitively with the configured ClassResolver (i.e. by default from the classpath). This will make detection of meta-annotations work out of the box now in many cases, without the need to explicitly import these meta-annotation types as well (see #342, #450; thanks a lot to @KorSin)
    • New method JavaClass.getBaseComponentType() (see #441; thanks a lot to @hankem)
    • Component types (i.e. String for an array String[]) are now detected as dependencies of JavaClass (see #257; thanks a lot to @wengertj)
    • New method ..archunit..Optional.getOrThrow(Supplier) (see #391; thanks a lot to @idosal)
    • New method JavaClass.getTransitiveDependenciesFromSelf() (see #401; thanks a lot to @hankem)

    Lang

    • New syntax members().that().haveName{StartingWith/Containing/EndingWith}(..) and members().should().haveName{StartingWith/Containing/EndingWith}(..) (see #239; thanks a lot to @kamer)
    • Improve CompositeArchRule.of(..) to accept an Iterable of ArchRule (see #384; thanks a lot to @sullis)
    • Clarify difference between access and depend in rule Javadocs (see #313; thanks a lot to @idosal)
    • New syntax classes().that().are{Not}Annotations() (see #468)
    • New syntax classes().that().doNotBelongToAnyOf(..) (see #422; thanks a lot to @perlun)

    Further Acknowledgement

    • Thanks a lot to @rweisleder for improving the ArchUnit user guide, development documentation and build
    • Thanks a lot to @spanierm for improving OS-JDK-matrix CI builds with GitHub Actions
    • Thanks a lot to @gernotstarke for website and documentation improvements (see #478 and #479)
    • Thanks a lot to @kamilszymanski and @dariuszzbyrad for Javadoc improvements and code cleanups
    • Thanks a lot to @sullis for upgrading various build dependencies
    • Thanks a lot to @cristiangreco for introducing Upgrade Gradle Wrapper Action (see #486)
    Source code(tar.gz)
    Source code(zip)
  • v0.14.1(May 23, 2020)

    Bug Fixes

    • Fix broken Gradle metadata: Migrating the legacy Maven Plugin to the Publish Plugin caused some broken Gradle metadata published to Maven Central by accident. While 0.14.0 should work fine with any other build tool like Maven, Gradle will complain about a missing artifact archunit-junit, which does in fact not exist. This release fixes this by removing the broken metadata.
    Source code(tar.gz)
    Source code(zip)
  • v0.14.0(May 23, 2020)

    Breaking Changes

    • All methods that have been deprecated up to ArchUnit 0.12.0 have been removed. It might make sense to look through your code for usage of deprecated methods and follow the advice in the Javadoc before upgrading (see #329; thanks a lot to @rweisleder for removing the old deprecations)

    Bug Fixes

    • Fix for Android where some classes were not imported correctly when run from the command line (see #319; also thanks a lot to @rweisleder for fixing the subsequent URI problems on Windows)
    • Fixed surprising behavior when using only{Call/Access}...That()... where the target of the call could not be resolved from the imported classes (see #340)

    Enhancements

    Core

    • JavaPackage now offers methods to retrieve the annotations of the respective package-info (see #263; thanks a lot to @rweisleder)
    • ClassFileImporter.importClasspath() now respects any ImportOptions passed via withImportOption(..) (see #296; thanks a lot to @rweisleder)
    • JavaMethod and JavaConstructor now have a heuristic line number instead of constant 0 (see #344; thanks a lot to @hankem)

    Library

    • The algorithm to detect cycles between slices has been improved from BFS to Johnson/Tarjan (see #138; thanks a lot to @torfmaster)
    • Cycle detection now has a configurable limit for the max number of cycles to detect (by default 100) and a max number of violations reported (by default 20 dependencies per edge). This can be reconfigured according to the user guide (see #326)
    • onionArchitecture() now supports to ignoreDependency(..) analogously to layeredArchitecture() (see #318; thanks a lot to @hankem)
    • There now is a rule to forbid field injection in favor of constructor injection (see #288; thanks a lot to @rweisleder)
    • There now is a rule to forbid dependencies on upper packages (see #151; thanks a lot to @qoomon for the initiative and POC)

    JUnit

    • @ArchIgnore, @ArchTag and @ArchTags are now usable as meta-annotations to compose custom annotations that inherit the behavior (analogous to https://junit.org/junit5/docs/current/user-guide/#writing-tests-meta-annotations; see #282; thanks a lot to @daniel-shuy)
    • Upgraded dependencies junit-platform-* from 1.5.2 to 1.6.2

    Further Acknowledgement

    • Thanks a lot to @aaschmid for extensive work to upgrade Gradle to the current version and to @jangalinski for the original initiative and draft (see #192, #284, #306 and #345)
    Source code(tar.gz)
    Source code(zip)
  • v0.13.1(Feb 4, 2020)

    Bug Fixes

    • Fixed java.lang.IllegalStateException: Couldn't find module modules of URI jrt:/... being thrown when trying to import JDK classes where JDK version >= 13. The path handling of JrtFileSystemProvider has been fixed according to JEP-220 with JDK 13. Unfortunately ArchUnit was dependent on the old behavior. (see #303)
    Source code(tar.gz)
    Source code(zip)
  • v0.13.0(Jan 10, 2020)

    Breaking Changes

    • While technically a very slim chance of really "breaking" anything, the log level of some details during the class file import has been reduced from DEBUG to TRACE (field, method, access and call details, ...) (see #291)

    Enhancements

    Core

    • Annotations and annotation parameters are now detected as dependencies. This could cause new findings when using the rules or library API. In particular JavaClass.getDirectDependencies{From/To}Self() will now also return Dependencies that originate from @FormerlyNotDetected or @Foo(someEnum = SomeEnumFormerlyNotDetected.FOO) or @Foo(bar = @Bar(type = SomeTypeFormerlyNotDetected.class)) (see #136; thanks a lot to @kosani)

    Lang

    • Some rule API method parameter types were invariant instead of contravariant (effectively preventing a predicate for a super type to be passed). These methods should now be fixed (see #262)
    • The rules API now offers more methods to filter and assert the type of class declaration ("top level class", "nested class", "member class", "inner class", "anonymous class" and "local class") (see #207; many thanks to @rweisleder)

    Library

    • FreezingArchRule by default now not only ignores line numbers, but also numbers after $ which effectively makes the ViolationStore resilient against changes in compiled lambda and anonymous class names (see #248; thanks a lot to @hankem)
    • LayeredArchitecture and OnionArchitecture now allow to configure optionalLayers(). In version 0.12.0 the behavior was made more strict, forbidding empty layers / parts of LayeredArchitecture and OnionArchitecture to prevent misconfiguration. This in turn unfortunately broke some valid use cases where empty / optional layers were in fact okay. In version 0.13.0 this is now completely configurable. By default it will still fail to prevent misconfiguration, but a switch of withOptionalLayers(true) or optionalLayer("Some Layer") will allow empty layers (and in turn empty parts of OnionArchitecture) (see #267 and #271; many thanks to @hankem)

    JUnit

    • there is now a ArchUnit JUnit 5 aggregator POM, i.e. instead of two dependencies archunit-junit5-api and archunit-junit5-engine, it is now also possible to simply add a single dependency archunit-junit5 with scope test / testCompile. Compare the user guide (see #272; thanks a lot to @eddumelendez)
    • Dependency upgrades (see #292)
      • junit-platform-* from 1.5.1 to 1.5.2
      • junit4 from 4.12 to 4.13 (in case of problems with archunit-junit4 it should be possible to exclude the transitive dependency to JUnit 4.13 and replace it by a custom 4.12 one)

    Further Acknowledgement

    • Many thanks to @Bananeweizen for fixing spelling and grammar mistakes in Javadoc / methods
    Source code(tar.gz)
    Source code(zip)
  • v0.12.0(Nov 3, 2019)

    Breaking Changes

    • So far ArchUnit's terminology has been a little sloppy with respect to the naming of inner and nested classes. By the JLS "inner classes" are those classes that are nested and not static. ArchUnit's API now reflects this via JavaClass.isNestedClass() versus JavaClass.isInnerClass(). Unfortunately this means that the method formerly called JavaClass.isInnerClass() will now return a different result, i.e. it will only return true, if the class is non-static. On the other hand, the method JavaClass.isNestedClass() will behave exactly like isInnerClass() did in ArchUnit 0.11.0 (see #224; thanks a lot to @rweisleder for the clarification and PR)
    • JavaAccessCondition does not filter self-accesses anymore. This was confusing behavior that did not solve the issue it was originally intended for. However, this might lead to additional violations showing up (see #209)

    Bug Fixes

    • Fixed bug where simple name of local classes was incorrect (see #216; thanks a lot to @rweisleder)
    • static modifier was missing from nested classes (see #219; thanks a lot to @rweisleder)

    Enhancements

    Core

    • Support for Java 14 (see #230; thanks a lot to @hankem)
    • JavaModifier now contains SYNTHETIC and BRIDGE allowing more introspection and filtering of synthetic members (see #243; thanks a lot to @alexfedorenchik)
    • Every property in archunit.properties can now be overwritten by passing a system property. This can be valuable in CI environments, e.g. to specify the ViolationStore path for FreezingArchRule. Compare the user guide (see #252)
    • A JavaClass representing an array can now be queried for its component type (see #187; thanks a lot to @alexfedorenchik)
    • JavaClass now offers a classpath independent version of getMethod(..) and getConstructor(..) (see #236; thanks a lot to @rweisleder)

    Lang

    • Extended syntax for classes().thatAreEnums() and classes()...should().beEnums() (see #172; thanks a lot to @rweisleder)

    Library

    • LayeredArchitecture now also checks that no layer is empty. While originally with good intentions, the ability to define empty layers turned out to do more harm than good (see #177; thanks a lot to @mikomatic)
    • LayeredArchitecture now allows layers to be defined by predicate. This allows for a way more flexible definition than simple package patterns (see #228; thanks a lot to @mikomatic)
    • FreezingArchRule can now be configured to be more strict, when checking rules. In particular it is possible to forbid updates of the ViolationStore or the creation of a new ViolationStore. This can serve as a safeguard in CI environments, where a missing ViolationStore is typically a misconfiguration. Compare the user guide (see #211; thanks a lot to @hankem for reviewing and providing valuable improvements)
    Source code(tar.gz)
    Source code(zip)
  • v0.11.0(Jul 30, 2019)

    Enhancements

    Core

    • DescribedPredicate now offers a more lambda compatible factory method DescribedPredicate.describe(description, predicate) (see #188; thanks a lot to @jzheaux)
    • New factory method DescribedPredicate.allElements(..) to complement DescribedPredicate.anyElementThat(..) (see https://github.com/TNG/ArchUnit/commit/b8890f447c3621cb16cb21e636b2a5397722c9ec)
    • Support for JDK 13 (see #195; thanks a lot to @jqno)
    • ArchUnits configuration (archunit.properties) and ignore patterns (archunit_ignore_patterns.txt) are now loaded with the ContextClassLoader instead of the ClassLoader of the respective class (see https://github.com/TNG/ArchUnit/commit/81c31f6b7ffd9c4836e1f8a0303724eb7f05ce83)

    Lang

    • New method classes().that().belongToAnyOf(..) to match any class or inner class of the passed classes (see #173; thanks a lot to @moboa)
    • New method classes().should().haveOnlyPrivateConstructors() (see #204; thanks a lot to @sullis)
    • New methods members().should().{have,notHave}FullName[Not][Matching](..) (see #205; thanks a lot to @hankem)

    Library

    • New FreezingArchRule to wrap any other ArchRule and change the behavior (see #181):
      • on the first run record all existing violations
      • on further runs only fail by unknown violations
      • also on further runs automatically decrease the stored violation count if existing violations are solved
      • compare the user guide
    • New Architectures.onionArchitecture() API offering a predefined API for Onion or Hexagonal Architectures, compare the user guide (see #174; thanks a lot to @spanierm)

    JUnit

    • The JUnit 5 platform dependency has been upgraded to version 1.5.1

    Further Acknowledgement

    • Thanks a lot to @hankem for adjusting Spotbugs to ignore false positives with JDK 9
    • Thanks a lot to @hankem for fixing incompatibilities of some tests with JDK 12
    • Thanks a lot to @vincent-fuchs for improving ArchUnit's logging
    • Thanks a lot to @sullis for upgrading dependencies
    Source code(tar.gz)
    Source code(zip)
  • v0.10.2(Mar 31, 2019)

    Bug Fixes

    • Fixed JavaPackage.getPackageDependenciesFromSelf() containing the package itself if there was a dependency in the same package but not directly imported (e.g. importer.importClasses(Foo.class) where some.pkg.Foo would depend on some.pkg.Bar, which was not imported)

    Enhancements

    Core

    • Some methods now return Collection types instead of Iterable to integrate nicer with streams

    Lang

    • FieldsShould now contains the negation notHaveRawTypes (see #162; thanks a lot to @asbachb)
    • CodeUnitsShould now contains the negations notHaveRawParameterTypes, notHaveRawReturnType and notDeclareThrowableOfType
    • The syntax now contains {methods,fields}().should().{be,notBe}{Static,Final} (see #164; thanks a lot to @hankem)

    Library

    • Slice now also offers dependenciesToSelf additionally to dependenciesFromSelf

    Further Acknowledgement

    • Thanks a lot to @hankem for reviewing and improving the user guide
    Source code(tar.gz)
    Source code(zip)
  • v0.10.1(Mar 17, 2019)

  • v0.10.0(Mar 17, 2019)

    Breaking Changes

    • The deprecated method String JavaClass.getPackage() was replaced by JavaPackage JavaClass.getPackage(). To query the package name, please use String JavaClass.getPackageName().
    • The deprecated method JavaClass.getDirectDependencies() has been removed -> use JavaClass.getDirectDependenciesFromSelf() instead
    • The deprecated field JavaClass.Functions.SIMPLE_NAME has been removed, please use JavaClass.Functions.GET_SIMPLE_NAME

    New Deprecation

    • ArchUnit does not use contractions anymore within the rules API. So far many methods were phrased like dontHave...() instead of doNotHave...(). In general this seems to be more trouble than worth it and does not read that well without an apostrophe, so all those methods were declared deprecated and have a new counter part without the contraction. A simple search & replace of dont by doNot should fix all those deprecations.
    • Some methods were deprecated because they were not precise enough, if generics come into play. For example JavaClass JavaField.getType() is not precise enough, because the type of a field is something else than a JavaClass (like T someField or List<? extends T> someField). Thus all those methods have been deprecated to make room for a future extension with generics and instead got a new version explicitly stating that the "raw type" is meant. For example JavaField.getType() -> JavaField.getRawType(), JavaMethod.getParameters() -> JavaMethod.getRawParameterTypes().
    • Formatters.formatLocation(JavaClass, lineNumber) was deprecated in favor of the newly introduced SourceCodeLocation.of(JavaClass, lineNumber) which will report the correct location (i.e. link for IDEs) via toString()

    Enhancements

    Core

    • The default class resolution behavior for classes missing from the import was changed. Before by default missing classes were replaced by stubs, now by default they will be resolved from the classpath. Compare the user guide (see #111)
    • JavaClass can now be queried for declared throws clauses, any Throwables declared on methods or constructors count as dependencies of a JavaClass (see #126; thanks a lot to @tngwoerleij)
    • JavaClass can now be queried if it is an array (see #114; thanks a lot to @wengertj)
    • The resolution of classes from the classpath will now use the context ClassLoader if set (should usually not make any difference, but allows to control the ClassLoader used by ArchUnit for class resolution)
    • JavaClass now has a more sophisticated JavaPackage attached to it. It is also possible to retrieve any JavaPackage from JavaClasses. JavaPackage offers a more convenient API for dependencies between packages (see #158; thanks a lot to @goetzd for reviewing and user guide adjustment)
    • For arrays JavaClass.getPackageName() now returns the package of the component type instead of empty. While empty is closer to the Java Reflection API, it is not really useful from a point of view of dependencies. Using an array of a type in a package should cause a dependency to that package (see #161)

    Lang

    • The rules API now provides an extensive support for checks of members / methods / fields (see #38; thanks a lot to @hankem for an extensive review and many improvements)

    Library

    • It is now possible to create a CompositeArchRule from several ArchRules to check multiple rules at once (see #78; thanks a lot to @bogsi17)
    • The PlantUML rules API now understands more types of arrows (description on arrows, arrows from right to left, arrow colors), compare the user guide (see #135)
    • New predefined rule to avoid the use of org.joda.time in favor of the java.time API (see #145; thanks a lot to @sullis)
    • The slices API is now more configurable to deal with inconsistent package structures and legacy projects. It is now possible to customize the assignment of JavaClasses to Slices by a simple function JavaClass -> Identifier, compare the user guide (see #156)

    JUnit

    • The JUnit 5 platform dependency has been upgraded to version 1.4.0.

    Further Acknowledgement

    • Thanks a lot to @alanktwong for improving the CONTRIBUTING docs on how to build the project
    • Thanks a lot to @wengertj for removing use of deprecated Gradle API
    • Thanks a lot to @olleolleolle for replacing the PNG build badge by SVG
    • Thanks a lot to @sullis for updating the Travis build to use OpenJDK 11
    Source code(tar.gz)
    Source code(zip)
  • v0.9.3(Nov 20, 2018)

    Bug Fixes

    Fixed memory leak in combination of the newly added ArchRule.AssertionError and JUnit 4. JUnit 4 keeps references to all thrown AssertionErrors through the whole run. Since ArchRule.AssertionError kept a reference to EvaluationResult this could consume a lot of memory, if the respective results were big. This release removes ArchRule.AssertionError (introduced in version 0.9.0).

    Note that this is in theory a breaking change, since it would have been possible to catch and process ArchRule.AssertionError. There does not seem to be any clean solution to this problem though, and due to the slim probability that the removal of this part of the API will in fact affect any user, the step seems justified.

    If anybody should against all odds have a problem with this, feel free to open an issue and we will find a different solution.

    Also ArchUnitTestEngine's engine id has been adjusted from junit-archunit to archunit to get rid of the warning JUnit 5 emits since version 1.3.0.

    Source code(tar.gz)
    Source code(zip)
  • v0.9.2(Nov 11, 2018)

    Enhancements

    • Added Java 11 support (see #117; thanks a lot to @hankem)
    • ArchUnitTestEngine's UniqueId is now archunit instead of junit-archunit to make it clear that it is not maintained by the JUnit 5 team
    Source code(tar.gz)
    Source code(zip)
  • v0.9.1(Aug 20, 2018)

    Bug Fixes

    • Fixed a bug where classes in Jars with white spaces (like Kotlin class files could have) cause an exception during the import (see #103)
    Source code(tar.gz)
    Source code(zip)
  • v0.9.0(Aug 19, 2018)

    Important

    The Maven coordinates for com.tngtech.archunit:archunit-junit have changed, since there is now support for JUnit 4 and JUnit 5. The new coordinates for the equivalent artifact are now

    com.tngtech.archunit:archunit-junit4:0.9.0
    

    Enhancements

    Core

    • archunit-ignore-patterns.txt can now contain comments (see #88; many thanks to @bedla)

    • a JavaClass' directDependenciesFromSelf and directDependenciesToSelf now contain further dependencies. This affects many rules as well, like layeredArchitecture() which might now detect more violations than before. In particular dependencies now contain dependencies from

      • fields of a certain type
      • method/constructor parameters of a certain type
      • method return types

      (see #92 and #96; many thanks to @msherman32)

    • the plugin mechanism activating Java >= 9 support now supports EA versions (see #93; many thanks to @jqno)

    Lang

    • the rule API now supports a concise way to assert properties of a single class (see #60; many thanks to @msherman32)
    • the rule API can now assert that classes haveOnlyFinalFields() (see #86; many thanks to @bgalek)
    • the rule API now allows to assert that there are at least / at most / exactly x classes matched by a rule (see #83; many thanks to @bedla)
    • rules can now be derived from PlantUML component diagrams (compare the User Guide; see #4; many thanks to @msherman32)
    • the rule API now allows to check more general for dependencies instead of just accesses (like interfaces, field types, method parameters, ...) (see #69)
    • the rule API now includes several methods to restrict what classes should "only" do, i.e. classes().should().onlyDependOnClassesThat()... or onlyCallMethodsThat(..), etc. (see #84)

    JUnit

    • ArchUnit now offers extended JUnit 5 support (compare the User Guide; see #34)

    Kotlin

    • rule suits with JUnit 4 / JUnit 5 can now be written in a concise way and source locations are reported correctly (compare the User Guide; see #77)
    Source code(tar.gz)
    Source code(zip)
  • v0.8.3(Jul 20, 2018)

    Bug Fixes

    Fixed bug where deeply nested super classes missing from the import were not resolved correctly from the classpath (see #91; many thanks to @svenackermann for reporting and debugging)

    Source code(tar.gz)
    Source code(zip)
  • v0.8.2(Jun 16, 2018)

    Bug Fixes

    Fixed a bug where the classpath property could not be parsed on Windows when using Eclipse Neon. Former versions of ArchUnit assumed all entries would be of the form C:\some\path (which seems to be the case for most IDEs/build tools), now also entries of the form /C:/some/path can be processed (see #79)

    Source code(tar.gz)
    Source code(zip)
  • v0.8.1(Jun 2, 2018)

    Bug Fixes

    • Fixed a bug where classes in Jars would not be imported on Windows, if Java version >= 9 and the whole classpath is imported; this only affects an import of the whole classpath with Jars, it does not affect importPackages(..), importPaths(..) or importJars(..) (see #73)

    Enhancements

    • When specifying a layeredArchitecture(), referring to a missing layer within onlyBeAccessedBy(..) will now throw an exception with a better error message (see #74)
    Source code(tar.gz)
    Source code(zip)
Owner
TNG Technology Consulting GmbH
TNG Technology Consulting GmbH is a value-based consulting partnership focused on high end information technology.
TNG Technology Consulting GmbH
Ready-to-use UI Test Automation Architecture using Java and Selenium WebDriver.

Selenium Test Automation Boilerplate Ready-to-use UI Test Automation Architecture using Java and Selenium WebDriver. Languages and Frameworks The proj

Tahanima Chowdhury 133 Dec 26, 2022
JUnit 5 Parameterized Test Yaml Test Data Source

Yamaledt — JUnit 5 Parameterized Tests Using Yaml and Jamal Introduction and usage Note This is the latest development documentation. This is a SNAPSH

Peter Verhas 4 Mar 23, 2022
Serenity BDD is a test automation library designed to make writing automated acceptance tests easier, and more fun.

That feeling you get when you know you can trust your tests Serenity BDD is a library designed to make writing automated acceptance tests easier, and

Serenity BDD 654 Dec 28, 2022
A library for setting up Java objects as test data.

Beanmother Beanmother helps to create various objects, simple and complex, super easily with fixtures for testing. It encourages developers to write m

Jaehyun Shin 113 Nov 7, 2022
AllPairs4J - an open source Java library for generation of minimal set of test combinations

AllPairs4J AllPairs4J is an open source Java library for generation of minimal set of test combinations. AllPairs4J is a Java port of allpairspy proje

Pavel Nazimok 5 Dec 11, 2022
Never debug a test again: Detailed failure reports and hassle free assertions for Java tests - Power Asserts for Java

Scott Test Reporter for Maven and Gradle Get extremely detailed failure messages for your tests without assertion libraries, additional configuration

Dávid Csákvári 133 Nov 17, 2022
A BDD-style test runner for Java 8. Inspired by Jasmine, RSpec, and Cucumber.

Spectrum A colorful BDD-style test runner for Java Spectrum is inspired by the behavior-driven testing frameworks Jasmine and RSpec, bringing their ex

Greg Haskins 143 Nov 22, 2022
Apache JMeter - An Open Source Java application designed to measure performance and load test applications

An Open Source Java application designed to measure performance and load test applications. By The Apache Software Foundation What Is It? Apache JMete

The Apache Software Foundation 6.7k Jan 1, 2023
Restful-booker API test automation project using Java and REST Assured.

Restful-booker API Test Automation Restful-booker API is an API playground created by Mark Winteringham for those wanting to learn more about API test

Tahanima Chowdhury 7 Aug 14, 2022
Gatling is a load test tool. It officially supports HTTP, WebSocket, Server-Sent-Events and JMS.

Gatling What is Gatling ? Gatling is a load test tool. It officially supports HTTP, WebSocket, Server-Sent-Events and JMS. Motivation Finding fancy GU

Gatling 5.8k Dec 27, 2022
A powerful open source test automation platform for Web Apps, Mobile Apps, and APIs

A powerful open source test automation platform for Web Apps, Mobile Apps, and APIs. Build stable and reliable end-to-end tests @ DevOps speed.

Testsigma Technologies Inc 466 Dec 31, 2022
A sample repo to help you handle basic auth for automation test in Java-selenium on LambdaTest. Run your Java Selenium tests on LambdaTest platform.

How to handle basic auth for automation test in Java-selenium on LambdaTest Prerequisites Install and set environment variable for java. Windows - htt

null 12 Jul 13, 2022
A sample repo to help you run automation test in incognito mode in Java-selenium on LambdaTest. Run your Java Selenium tests on LambdaTest platform.

How to run automation test in incognito mode in Java-selenium on LambdaTest Prerequisites Install and set environment variable for java. Windows - htt

null 12 Jul 13, 2022
A sample repo to help you handle cookies for automation test in Java-selenium on LambdaTest. Run your Java Selenium tests on LambdaTest platform.

How to handle cookies for automation test in Java-selenium on LambdaTest Prerequisites Install and set environment variable for java. Windows - https:

null 13 Jul 13, 2022
A sample repo to help you set geolocation for automation test in Java-selenium on LambdaTest. Run your Java Selenium tests on LambdaTest platform.

How to set geolocation for automation test in Java-selenium on LambdaTest Prerequisites Install and set environment variable for java. Windows - https

null 12 Jul 13, 2022
A sample repo to help you capture JavaScript exception for automation test in Java-selenium on LambdaTest. Run your Java Selenium tests on LambdaTest platform.

How to capture JavaScript exception for automation test in Java-selenium on LambdaTest Prerequisites Install and set environment variable for java. Wi

null 12 Jul 13, 2022
A sample repo to help you find an element by text for automation test in Java-selenium on LambdaTest. Run your Java Selenium tests on LambdaTest platform.

How to find an element by text for automation test in Java-selenium on LambdaTest Prerequisites Install and set environment variable for java. Windows

null 12 Jul 13, 2022
A sample repo to help you emulate network conditions in Java-selenium automation test on LambdaTest. Run your Java Selenium tests on LambdaTest platform.

How to emulate network conditions in Java-selenium automation test on LambdaTest Prerequisites Install and set environment variable for java. Windows

null 12 Jul 13, 2022
PowerMock is a Java framework that allows you to unit test code normally regarded as untestable.

Writing unit tests can be hard and sometimes good design has to be sacrificed for the sole purpose of testability. Often testability corresponds to go

PowerMock 3.9k Dec 28, 2022