Testing package dependencies with Degraph #71
Conversation
The test currently fails due to a dependency from org.junit.gen5.engine.junit5.descriptor to org.junit.gen5.engine.junit5 In Tests, while there exists plenty of dependencies in the other direction in other code
The dependency caused a dependency circle on package level The Test wasn't really related to the JUnit5TestEngine, it just needed an Engine with an id.
The dependency caused a dependency circle on package level The Test wasn't really related to the JUnit5TestEngine, it just needed an Engine with an id.
The checks between modules is somewhat redundant, since it should already be enforced by code conventions plus gradle. Also added a comment for the test.
Gradle includes dependencies to other modules as jar files, so Degraph won't see them if we tell it to ignore jars.
removing the noJar() enabled analysis of JUnit classes. Fixed this by making the include more strict. Also tried to find a compromise between readable code layout and what spotlessApply does
Current coverage is
|
|
|
||
| testRuntime("org.apache.logging.log4j:log4j-core:${log4JVersion}") | ||
| testRuntime("org.apache.logging.log4j:log4j-jul:${log4JVersion}") |
There was a problem hiding this comment.
Ooops, by accident. I'll put it back in.
|
@schauder Thanks for the PR! Just one minor question in the diff. |
| * http://www.eclipse.org/legal/epl-v10.html | ||
| */ | ||
|
|
||
| package org.junit.gen5.commons.util.org.junit.gen5.meta; |
There was a problem hiding this comment.
Should be just org.junit.gen5.meta, right?
|
@schauder Is there a way to tell degraph that |
|
For legal reasons you'll have to add a paragraph to the pull request description that states that you agree to the terms in https://github.com/junit-team/junit-lambda/blob/master/CONTRIBUTING.md |
|
@marcphilipp it is possible and NamedPatterns are the way to go (although you could achieve it without them) You probably used the parameters in the wrong oder. No idea why I put them the way they are ... See the latest commit. |
|
@jlink done. Pulling out org.junit.Assert right now and replacing it with import static org.hamcrest.MatcherAssert.assertThat; |
|
@schauder Thanks! I've merged this pull request manually. Great to finally have this check in place. 👍 |
|
I'd like to pull |
|
I agree with @jlink: |
|
While I agree that it is to slow for the first build step of a CI pipeline, I prefer to let it run after every push, but in a separate build step. Another alternative would be to include such a test in each project. Since it would only run on the classes (not the jar files) it should be much faster, although still not as fast as one would wish for a proper Unit test. |
|
I don't really mind to have it as a precommit step or in the ci build. But I also want a very fast test suite to run (more or less) continuously. @schauder Did you think about externalizing the use of the tool into a gradle/maven plugin that gets a DSL like configuration block? This would give users the freedom to use it in the way best fit for their project setup. |
|
@jlink Yes: riy/degraph#62 |
Adds a test that tests for dependency cycles on package an module level.
Modules in this sense are all classes that start with the same package: org.junit.gen5.x
In order to make the test pass I had to break to dependencies from test to the JUnit5TestEngine. Since the engine wasn't really part of the test, I replaced it with a mock.
I agree to https://github.com/junit-team/junit-lambda/blob/master/CONTRIBUTING.md