Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-4659

Introduce AssertJ and gradually migrate to its usage instead of Hamcrest

    XMLWordPrintableJSON

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

          Activity

            People

              Unassigned Unassigned
              vladimirsitnikov Vladimir Sitnikov
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated: