It is possible to write custom assertions classes based on multiple AbstractAssert classes from AssertJ. When doing so, implementation of RSPEC-5853, unfortunately, does not report issues, while it's the same mechanism that is expected.
class MyTestClass { @Test void nonCompliantTypeTest() { MyType myType = new MyType(); Assertions.assertThat(myType).isNotNull(); // TP: ask to chain methods Assertions.assertThat(myType).isEqualTo(new MyType()); CustomAssert.assertThat(myType).isFoo(); // FN: do not ask to chain methods, while it is possible CustomAssert.assertThat(myType).isBar(); } @Test void compliantTypeTest() { MyType myType = new MyType(); Assertions.assertThat(myType) .isNotNull() .isEqualTo(new MyType()); CustomAssert.assertThat(myType) .isFoo() .isBar(); } public static class CustomAssert extends AbstractAssert<CustomAssert, MyType> { private CustomAssert(MyType actual) { super(actual, CustomAssert.class); } public static CustomAssert assertThat(MyType actual) { return new CustomAssert(actual); } public CustomAssert isFoo() { return this; } public CustomAssert isBar() { return this; } } public static class MyType { } }
- relates to
-
RSPEC-5853 Consecutive AssertJ "assertThat" statements should be chained
- Active