FEST

ignoringCase() feature for String assert

Details

  • Type: New Feature New Feature
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: FEST-Assert 1.2
  • Fix Version/s: FEST-Assert 1.3
  • Component/s: Assert
  • Labels:
    None
  • Number of attachments :
    1

Description

Hello,

1. I had to do it myself so I think it might be useful for others:

assertThat(someString).containsIgnoringCase("foo");

2. You might also consider adding .equalsIgnoringCase(other) because java5 already has such method on String. However, I didn't need such assertion yet.

3. There's an option to do it fluently: assertThat(someStr).ignoringCase().contains("foo"), however I think I like simple option #1 more.

Issue Links

This issue is related to:
FEST-64 Assertions should be allowed to compare objects using a custom comparator instead of equals() Major Resolved

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Joel Costigliola added a comment -

Hi Alex and Yvonne,

Alex, I sent you a patch for this issue, maybe it's not necessary that Yvonne works on that.
The patch I sent you is attached to the issue.
Yvonne can review it and tell it it's ok ?

Cheers,

Joel

Show
Joel Costigliola added a comment - Hi Alex and Yvonne, Alex, I sent you a patch for this issue, maybe it's not necessary that Yvonne works on that. The patch I sent you is attached to the issue. Yvonne can review it and tell it it's ok ? Cheers, Joel
Hide
Permalink
Ansgar Konermann added a comment -

Item 2 is probably a duplicate of FEST-171.

I really like option 3, which I also considered for FEST-171, but resorted to just using isEqualToIgnoringCase, since this is simpler/quicker to implement and thus provides value to the FEST-Assert users sooner.

Besides, I tend to believe that option 3 is an example of a general pattern useful whenever we might want to influence the behaviour of how FEST should compare values:

asserThat(actual).<comparisonConfigurationCall>().<checkMethodCall>(expected);

Where comparisonConfigurationCall would just set an appropriate strategy object or functor in the Assertion instance returned by assertThat(). Without this call, the Assertion instance is configured with a default strategy object. The "strategy object" could also be a java.lang.Comparator<T> in many cases.

This pattern is also part of one of the solutions Ted suggested for FEST-64.

If we'd store the strategy object inside the Assertion instance, we could even solve the problem of using multiple different comparators one after another. We simply needed to allow the configuration method call to be interspersed into the fluent sentence whenever we want (which is of course easily done by just making it a regular method of the respective Assertion class).

I'd be willing to implement an example showing this can work, maybe either for this issue or FEST-64 and write a little article summarizing how it's implemented. If everything goes well, we might be able to put a lot more flexibility into FEST-Assertions by allowing on-demand configuration of various aspects, mainly comparison of values.

Show
Ansgar Konermann added a comment - Item 2 is probably a duplicate of FEST-171. I really like option 3, which I also considered for FEST-171, but resorted to just using isEqualToIgnoringCase, since this is simpler/quicker to implement and thus provides value to the FEST-Assert users sooner. Besides, I tend to believe that option 3 is an example of a general pattern useful whenever we might want to influence the behaviour of how FEST should compare values: asserThat(actual).<comparisonConfigurationCall>().<checkMethodCall>(expected); Where comparisonConfigurationCall would just set an appropriate strategy object or functor in the Assertion instance returned by assertThat(). Without this call, the Assertion instance is configured with a default strategy object. The "strategy object" could also be a java.lang.Comparator<T> in many cases. This pattern is also part of one of the solutions Ted suggested for FEST-64. If we'd store the strategy object inside the Assertion instance, we could even solve the problem of using multiple different comparators one after another. We simply needed to allow the configuration method call to be interspersed into the fluent sentence whenever we want (which is of course easily done by just making it a regular method of the respective Assertion class). I'd be willing to implement an example showing this can work, maybe either for this issue or FEST-64 and write a little article summarizing how it's implemented. If everything goes well, we might be able to put a lot more flexibility into FEST-Assertions by allowing on-demand configuration of various aspects, mainly comparison of values.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.