FEST
  1. FEST
  2. FEST-133

DoubleAssert.isEqualTo() behaviour change?

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: FEST-Assert 1.1
    • Fix Version/s: FEST-Assert 1.3
    • Component/s: Assert
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Hi there,

      I've just upgraded to FEST 1.1 and I've noticed that the behaviour of DoubleAssert.isEqualTo() might have changed from previous version (I was upgrading from 1.01a). Previously assertThat((Double)null).isEqualTo(null), would pass, while now it throws a NullPointerException. Is this the intended behaviour? One way to deal with this would be to use assertThat(Object).isEqualTo(Object), but then we won't be able to provide a delta...

      To sum up, ideally the signature could be DoubleAssert.isEqualTo(Double) and be null-aware as previously.

      Thanks!

      S.

      PS. Using plain code names unaccompanied by the actual release version in JIRA might be confusing for people trying to determine the right Affects Version (the downloads section on the website uses numbers rather than code names)

        Issue Links

          Activity

          Hide
          Alex Ruiz added a comment -

          Totally agree with you!

          I think we can finally remove PrimitiveAssert and have a single hierarchy for all assertions. Yay!

          Thanks!
          -Alex

          Show
          Alex Ruiz added a comment - Totally agree with you! I think we can finally remove PrimitiveAssert and have a single hierarchy for all assertions. Yay! Thanks! -Alex
          Hide
          Alex Ruiz added a comment -

          Oh BTW, there is a new class ComparableAssert, which is superclass of BigDecimalAssert. I think all assertions for numbers can extend this class and implement NumberAssert to minimize code duplication.

          Show
          Alex Ruiz added a comment - Oh BTW, there is a new class ComparableAssert , which is superclass of BigDecimalAssert . I think all assertions for numbers can extend this class and implement NumberAssert to minimize code duplication.
          Hide
          Ansgar Konermann added a comment - - edited

          I recently found out you refactored all the unit tests. Seems like they are already structured according to certain "groups of checks". Looks very good, yet I immediately had the idea we might be able to reduce test code a lot. Here's my story...

          A week ago or so, my colleagues and me were so lucky to view a presentation by J. B. Reinsberger (author of "JUnit Receipes") about testing http://www.infoq.com/presentations/integration-tests-scam. He advocated a testing style comprised of interaction tests and contract tests. Whenever two objects interact, put in interfaces between them, test each object in isolation with the other object(s) replaced by test doubles. I'll skip interaction tests. The second half of the testing strategy is what he calls "contract tests". They essentially make sure that each and every implementation in my system which claims to implement an interface actually obeys its contract..

          I recognized there are probably similar patterns in FEST-Assert. In other words: I believe there are groups of assertion classes, which implement a number of interfaces, with the interfaces defining a contract.

          "ComparableAssert" is, in my eyes, one of these contracts. It might also be termed an "abstract contract", or in Java terms "generic contract", because it can be applied to a number of concrete types, which of course must be comparable. I'm quite sure we can identify most of the assertions we currently support belong to a contract of some form. More examples could be: NullableAssert (isNull, isNotNull), GroupAssert (hasSize, isEmpty, isNotEmpty), ...

          Last weekend, I drafted some experimental code which is intended to support systematic contract testing. It basically ensures that, whenever you define an interface (and annotate it as @Contract), all the implementors of this contract are tested to comply to the contract. This is done by creating a number of tests on dynamically (for TestNG at the moment, since we use TestNG at work), but I think it can easily be ported to JUnit; probably by defining a custom TestSuite). It aims at defining the test code once per abstract contract, and provide the relevant test data on a per-concrete-contract-basis. I. e. imagine:

          interface ComparableAssert<T> as the abstract contract, and BigDecimalAssert implements ComparableAssert<BigDecimal> as an implementor of a concrete contract derived from ComparableAssert. In this setting, you'd define one (generic) test to check that each implementor obeys to ComparableAssert, and one test data factory for each concrete contract (e. g. ComparableAssert<BigDecimal>).

          I'm planning to make this testing aid a github project once it's at least a bit useful. I'm not sure it works out for generic contracts, so no jumping for joy yet. What do you think?

          Show
          Ansgar Konermann added a comment - - edited I recently found out you refactored all the unit tests. Seems like they are already structured according to certain "groups of checks". Looks very good, yet I immediately had the idea we might be able to reduce test code a lot. Here's my story... A week ago or so, my colleagues and me were so lucky to view a presentation by J. B. Reinsberger (author of "JUnit Receipes") about testing http://www.infoq.com/presentations/integration-tests-scam . He advocated a testing style comprised of interaction tests and contract tests. Whenever two objects interact, put in interfaces between them, test each object in isolation with the other object(s) replaced by test doubles. I'll skip interaction tests. The second half of the testing strategy is what he calls "contract tests". They essentially make sure that each and every implementation in my system which claims to implement an interface actually obeys its contract.. I recognized there are probably similar patterns in FEST-Assert. In other words: I believe there are groups of assertion classes, which implement a number of interfaces, with the interfaces defining a contract. "ComparableAssert" is, in my eyes, one of these contracts. It might also be termed an "abstract contract", or in Java terms "generic contract", because it can be applied to a number of concrete types, which of course must be comparable. I'm quite sure we can identify most of the assertions we currently support belong to a contract of some form. More examples could be: NullableAssert (isNull, isNotNull), GroupAssert (hasSize, isEmpty, isNotEmpty), ... Last weekend, I drafted some experimental code which is intended to support systematic contract testing. It basically ensures that, whenever you define an interface (and annotate it as @Contract), all the implementors of this contract are tested to comply to the contract. This is done by creating a number of tests on dynamically (for TestNG at the moment, since we use TestNG at work), but I think it can easily be ported to JUnit; probably by defining a custom TestSuite). It aims at defining the test code once per abstract contract, and provide the relevant test data on a per-concrete-contract-basis. I. e. imagine: interface ComparableAssert<T> as the abstract contract, and BigDecimalAssert implements ComparableAssert<BigDecimal> as an implementor of a concrete contract derived from ComparableAssert. In this setting, you'd define one (generic) test to check that each implementor obeys to ComparableAssert, and one test data factory for each concrete contract (e. g. ComparableAssert<BigDecimal>). I'm planning to make this testing aid a github project once it's at least a bit useful. I'm not sure it works out for generic contracts, so no jumping for joy yet. What do you think?
          Hide
          Alex Ruiz added a comment -

          Ansgar, I just love your idea! Really, really cool and useful!

          I'm very curious to see how you generate tests dynamically...please ping me when the project is up!

          Show
          Alex Ruiz added a comment - Ansgar, I just love your idea! Really, really cool and useful! I'm very curious to see how you generate tests dynamically...please ping me when the project is up!
          Hide
          Ansgar Konermann added a comment -

          Fixed in trunk. Alex is doing some cleanup as part of FEST-260, but this issue is already resolved.

          Show
          Ansgar Konermann added a comment - Fixed in trunk. Alex is doing some cleanup as part of FEST-260 , but this issue is already resolved.

            People

            • Assignee:
              Ansgar Konermann
              Reporter:
              Stanislaw Osinski
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: