You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Change rule evaluation to also require positive results by default
The change is intended to make it easier to detect ineffective rules,
as you can see in the example unit test. This change obviously breaks
some tests, so it can be defeated per rule with a call to
.WithoutRequiringPositiveResults().
Should().Exist() and NotExist() rules automatically defeat the check
so their error messages should remain stable. However, the logic to check
for (non)exitence had to be modified which may cause inconvenience.
The implemetation basically treats an empty result set as a non-passing
result (i.e. a violation).
The change breaks a lot of unit tests, mostly those which iterate
over a bunch of test types and are tautologies. This issue is adressed
in a subsequent commit.
Signed-off-by: Simon Thum <sthum@meddv.de>
$"The rule requires positive evaluation, not just absence of violations. Use {nameof(WithoutRequiringPositiveResults)}() or improve your rule's predicates.",
"\"Classes that are \"ArchUnitNETTests.Domain.PublicTestClass\" should be private\" failed:"+
56
60
NewLine+"\tArchUnitNETTests.Domain.PublicTestClass is public"+NewLine+
@@ -108,6 +112,10 @@ public class RuleEvaluationTests
108
112
NewLine+"\tArchUnitNETTests.Domain.PublicTestClass does exist and is public"+
109
113
NewLine+NewLine;
110
114
115
+
privatereadonlystring_expectedWrongArchRule9ErrorMessage="\"Classes that have name \"NotTheNameOfAnyClass_1592479214\" should be private\" failed:"+NewLine+
116
+
"\tThe rule requires positive evaluation, not just absence of violations. Use WithoutRequiringPositiveResults() or improve your rule's predicates."+
117
+
NewLine+NewLine;
118
+
111
119
[Fact]
112
120
publicvoidAssertArchRuleTest()
113
121
{
@@ -133,6 +141,8 @@ public void AssertArchRuleTest()
0 commit comments