Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
AssertJ has already been discussed in CALCITE-2457, yet it was forgotten.
Note: I do not suggest replacing all the assertions with AssertJ, especially "compare with golden output" ones.
The current issues with assertThat-based tests:
1) asertTrue, assertEquals(Object, Object) are prone to mistakes so one can get "expected vs actual wrong".
2) Hamcrest matches are hard to discover. In other words, one cant use autocomplete menu in IDE to see which other matches are available.
3) Hamcrest matches are hard to extend/implement. For instance, we have very limited amount of Hamcrest-based matches, and we do have a lot of Calcite-specific assertions.
AssertJ solves the issue of API discoverability (one writes assertThat(...).containsExactly("skippedTest")), and AssertJ has a well-known path for extensibility. We can implement Calcite-specific assertions with AssertJ style, so the tests would be more consistent.
Refaster templates (see CALCITE-4658) might help to perform automatic conversion from JUnit-style assertions to AssertJ.
There are templates to cleanup AssertJ assertions: https://github.com/palantir/assertj-automation
Attachments
Issue Links
- relates to
-
CALCITE-4885 Fluent test fixtures so that dependent projects can write parser, validator and rules tests
- Closed