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
<propertyname="message"value="Please use BDDMockito."/>
<propertyname="ignoreComments"value="true"/>
</module>
... that rule does not actually enforce anything.
For example, it's still possible to statically import methods declared in Mockito via BDDMockito, and that has happened numerous times across the code base.
During a team discussion, we decided that the team currently has no preference regarding BDDMockito stubbing APIs over traditional Mockito stubbing APIs. In addition, certain IDEs (for example, Eclipse) covert static imports for org.mockito.BDDMockito.when to org.mockito.Mockito.when which then fails the Gradle build even though the latter import is technically more correct.
In light of that, we have decided to simply remove the BDDMockito Checkstyle rule.
The text was updated successfully, but these errors were encountered:
Although we have a Checkstyle rule which attempts to enforce the use of
BDDMockito
...spring-framework/src/checkstyle/checkstyle.xml
Lines 223 to 229 in ce81500
... that rule does not actually enforce anything.
For example, it's still possible to statically import methods declared in
Mockito
viaBDDMockito
, and that has happened numerous times across the code base.During a team discussion, we decided that the team currently has no preference regarding
BDDMockito
stubbing APIs over traditionalMockito
stubbing APIs. In addition, certain IDEs (for example, Eclipse) covert static imports fororg.mockito.BDDMockito.when
toorg.mockito.Mockito.when
which then fails the Gradle build even though the latter import is technically more correct.In light of that, we have decided to simply remove the
BDDMockito
Checkstyle rule.The text was updated successfully, but these errors were encountered: