Lenient Equals based on reflection

Oups, not a major issue but a minor (I cannot find how edit this issue).

This could be a nice addition !
I'm gonna set the fix version to 2.0, don't worry if it's not in M1, I'm planning to make frequent releases so it will release a M2 if needed.

I would just rename isLenientEqualsToByIgnoringNull to isLenientEqualsToByIgnoringNullFields, the first time I read the assertion, I wasn't sure of what could be null, it would also be consistent with the other assertions that ends with Fields.

I guess that the assertions method isLenientEqualsToByAcceptingFields and isLenientEqualsToByIgnoringFields will use a vararg for fields parameter.

Have thought of error messages, can you give me some examples ?

Actually you can already do such assertions with Fest 2.0 by using a specific comparison strategy, but it needs more work for users as they need to create a specific Comparator.
The advantage being that all assertions will honor the specific comparison strategy, for example isIn or contains and not only isEqual.

Examples extracted from https://github.com/joel-costigliola/fest-examples/blob/master/src/main/java/org/fest/assertions/examples/AssertionsWithCustomComparatorExamples.java :

 // standard comparison : frodo is not equal to sam ...
 assertThat(frodo).isNotEqualTo(sam);
 // ... but if we compare only character's race frodo is equal to sam
 assertThat(frodo).usingComparator(raceNameComparator).isEqualTo(sam).isEqualTo(merry).isEqualTo(pippin);
 
 // isIn assertion should be consistent with raceComparator :
 assertThat(frodo).usingComparator(raceNameComparator).isIn(sam, merry, pippin);
 
 // chained assertions use the specified comparator, we thus can write
 assertThat(frodo).usingComparator(raceNameComparator).isEqualTo(sam).isIn(merry, pippin);

 // standard comparison : the fellowshipOfTheRing includes Gandalf but not Sauron ...
 assertThat(fellowshipOfTheRing).contains(gandalf).doesNotContain(sauron);
 // ... but if we compare only race name Sauron is in fellowshipOfTheRing because he's a Maia like Gandalf.
 assertThat(fellowshipOfTheRing).usingComparator(raceNameComparator).contains(sauron);

Yes isLenientEqualsToByIgnoringFields & isLenientEqualsToByAcceptingFields use a vararg for fields parameters.

Looking back this feature, I think it could be nice to have a reflexion equals fields by fields instead of writing :

assertThat(jedi1).isLenientEqualsToByIgnoringFields(jedi2); // Don't ignore fields

More readable to write something like that :

assertThat(jedi1).isReflectionEquals(jedi2); 

Getting back to error message for all :

expected values <["Yoda"]> to fields <["name"]> in <YodaJedi>

I had thought of using the comparator but I thought it got a lot of unused method with this feature.
Just "areEquals" seam be interesting and I know how define the "isGreaterThan". Throws a UnsupportedOperationException ?

But no problems to use it
I think we should create a "org.fest.assertions.comparator" package.
AbstractComparisonStrategy can be used, but I think the 4 comparators need a common ComparisonStrategy (a AbstractReflectionComparisonStrategy extends AbstractComparisonStrategy).

The assertion below is really counter intuitive, I actually understand it as "we are ignoring all fields", but it was just the opposite.

assertThat(jedi1).isLenientEqualsToByIgnoringFields(jedi2);

If we are comparing objects field by field, I would prefer something like :

assertThat(jedi1).isLenientEqualsToByComparingFieldByField(jedi2);

Here I must say I don't get why would I use a field by field comparison over equals method ?
I don't remember having the need of such an assertion, have you met a real use case for that at work ?
I don't say we are not doing it, I'm just curious why someone would need that.

On the error message, I would suggest (if you find it clearer) :

expected values <["Yoda"]> in fields <["name"]> of <YodaJedi>

and maybe if there's only one field used

expected value <"Yoda"> in field <"name"> of <YodaJedi>

For the comparison strategy, I was just mentioning it, I don't have yet any opinion on lenient equals implementation.
So let's try to implement it and see what it's like ...

I understand that this is not a commonly used, but I use it.
On some projects, we use gwt with dozer. I want to check if the fields of the object are copied (The source are target are the same type). Today, we use a condition.
In writing this use case, I am thinking to another use cases : other projects also use dozen but source are target are not the same type.
This kind of equals is a deep comparison.

So I think, this feature could be interesting but should be should be well thought and be another issue.
Finally this issue concerns only 3 lenients equals from start.

Thanks to Nicolas Francois for addressing this feature !

Hi, I really like this feature and I'm already using it. but I would also like to have method that just compares all fields (even the nulls)
Like this:

 
assertThat(jedi1).isLenientEqualsTo(jedi2);

Now I'm using 'isLenientEqualsToByIgnoringFields' to get this functionality. (but without ignored fields)

 
assertThat(jedi1).isLenientEqualsToByIgnoringFields(jedi2);

Maybe add 'isLenientEqualsTo(Object)' that calls 'isLenientEqualsToByIgnoringFields' ? (for code readability sake.)

Thanks

Hi Bram,

Issue has been moved to github - our official issue tracker from now on - here :
https://github.com/alexruiz/fest-assert-2.x/issues/22

Give us your thoughts on Nicolas and my comments.

Cheers,

Joel