-
Notifications
You must be signed in to change notification settings - Fork 282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Verify that the rule input is not empty #774
Conversation
[jenv](https://www.jenv.be/) can be used to manage multiple JDK installations and configure each codebase to use a specific JDK version without having to change the JAVA_HOME environment variable. Therefore, a file `.java-version` is created. Since this should not be part of the project, it is ignored. Signed-off-by: Hannes Oberprantacher <h.oberprantacher@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for this 😄 I'm sure this will be super useful for users!
I looked over it and added some comments 🙂 I like the first commit you did separately and explained well! 👍 In generally the commits are described very well 🙂 I would still suggest we squash the 2nd and the 3rd commit. Because the 3rd commit is a direct consequence of the 2nd one, and also we don't want to have any state in the repository that doesn't run successfully (i.e. no matter which commit I check out, I want gradlew build
to pass successfully).
archunit/src/test/java/com/tngtech/archunit/lang/ArchRuleTest.java
Outdated
Show resolved
Hide resolved
archunit/src/test/java/com/tngtech/archunit/lang/ArchRuleTest.java
Outdated
Show resolved
Hide resolved
archunit/src/test/java/com/tngtech/archunit/lang/ArchRuleTest.java
Outdated
Show resolved
Hide resolved
archunit/src/test/java/com/tngtech/archunit/lang/syntax/elements/GivenClassesThatTest.java
Outdated
Show resolved
Hide resolved
archunit/src/test/java/com/tngtech/archunit/lang/ArchRuleTest.java
Outdated
Show resolved
Hide resolved
The input for the should-part of a rule should normally not be empty, since then the test will always be green because it doesn't test anything. With this change, it is now possible to verify that the input of a rule is not empty. If the input is empty, an `AssertionError` is thrown. The verification if the input is empty can also be controlled via the configuration. By setting the value `archRule.failOnEmptyShould` to `true` or `false`, we can turn on or off the verification. The default value is `true` which means this is a breaking change. However, with the configuration, the old behavior can easily be restored. Since ArchUnit's core unit tests are often no "realistic" architecture tests we have disabled the property in the core unit tests. To test the default behavior we thus need to remove the property from `archunit.properties`. However, we want to avoid adding a new public method to `ArchConfiguration`, which might be a little confusing, since users can also override these properties with system properties which makes the remove behavior not completely clear. So, in order to remove the property without public API we have added a test utility method instead that removes the property via Reflection. Signed-off-by: Hannes Oberprantacher <h.oberprantacher@gmail.com>
The input for the should-part of a rule should normally not be empty, since then the test will always be green because it doesn't test anything.
With this change, it is now possible to verify that the input of a rule is not empty. If the input is empty, an
AssertionError
is thrown.The verification if the input is empty can also be controlled via the configuration.
By setting the value
archRule.failOnEmptyShould
totrue
orfalse
, we can turn on or off the verification.The default value is
true
which means this is a breaking change.However, with the configuration, the old behavior can easily be restored.
Resolve #178