So far, if we include rules from other test classes, e.g.
@AnalyzeClasses(..)
class ExampleTest {
@ArchTest
static final ArchTests nested = ArchTests.in(Other.class);
}
then the included class (Other.class in this case) will be used as test location.
This can cause confusion, because by this if Other.class is included in two separate test classes,
analyzing different locations via @AnalyzeClasses,
the results will be reported for the same test class Other.class.
We now report the outermost class that started the test (the one with `@AnalyzeClasses)
as the test location for both JUnit 4 and JUnit 5.
To make it easy to understand through which path a rule is included in more complex scenarios,
we extend the display name to include the path of nested classes.
So far, if we include rules from other test classes, e.g.
then the included class (
Other.class
in this case) will be used as test location. This can cause confusion, because by this ifOther.class
is included in two separate test classes, analyzing different locations via@AnalyzeClasses
, the results will be reported for the same test classOther.class
. We now report the outermost class that started the test (the one with `@AnalyzeClasses) as the test location for both JUnit 4 and JUnit 5. To make it easy to understand through which path a rule is included in more complex scenarios, we extend the display name to include the path of nested classes.Resolves: #452