[testng-dev] org.testng.Assert.assertEquals(Collection<?> actual, Collection<?> expected, String message)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[testng-dev] org.testng.Assert.assertEquals(Collection<?> actual, Collection<?> expected, String message)

Kevin Connor Arpe
Hello,

I am regular user of TestNG, and I love it -- especially the "DataProvider" feature.

Ref: org.testng.Assert.assertEquals(Collection<?> actual, Collection<?> expected, String message)
I noticed tonight that this static method completely avoids calling actual.equals(expected) and expected.equals(actual).  This was a surprise to me.

I was testing some classes that extend Collection<T>, but add one or two methods.

What if we add a little logic to the end of the method (if all logic above succeeds): [thinking out loud]
assertTrue(
    actual.equals(expected) && expected.equals(actual),
    String.format(
        "All elements equal via iteration, but equals(Object) method failed%n\tActual class: %s%n\tExpected class: %s",
        actual.getClass().getName(),
        expected.getClass().getName());

Even better would be to test "both directions", and report any strange results, e.g.,
boolean actual_vs_expected = actual.equals(expected);
boolean expected_vs_actual = actual.equals(expected);
if (actual_vs_expected != expected_vs_actual) {
    // report nice error message
}

As a guess, it seems the Collection<T> specialised form was written to provide nicer error reporting.  That is all good.  It is helpful in many cases.  I am asking for something a bit more.

Further, after reviewing this email, I realise that implementing the Collection<T> interface (or any sub-interface), but adding additional data not accessible via iterator() is probably a Very Bad Idea.
For example: AbstractList<T> (super class for ArrayList<T>) implements equals() by comparing iterators from both the lists.  This would violate the symmetric property of equals().
All said, I would still like to know this bad scenario has happened between collections.  The bit above "if (actual_vs_expected != expected_vs_actual)" would catch exactly this violation of symmetric property.

Please share your thoughts.

Kind regards,
Kevin Connor ARPE
Hongkong

--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/testng-dev.
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: [testng-dev] org.testng.Assert.assertEquals(Collection<?> actual, Collection<?> expected, String message)

Tomek Kaczanowski-3
Hi Kevin

I can't really answer your question for very simple reason. Long time
ago I have abandoned TestNG assertions and moved to AssertJ. And I
think that is the real solution to any assertion problem that you
have. AssertJ or Hamcrest, whichever one suits you better.

Cheers!

2014/1/6 Kevin Connor Arpe <[hidden email]>:

> Hello,
>
> I am regular user of TestNG, and I love it -- especially the "DataProvider"
> feature.
>
> Ref: org.testng.Assert.assertEquals(Collection<?> actual, Collection<?>
> expected, String message)
> I noticed tonight that this static method completely avoids calling
> actual.equals(expected) and expected.equals(actual).  This was a surprise to
> me.
>
> I was testing some classes that extend Collection<T>, but add one or two
> methods.
>
> What if we add a little logic to the end of the method (if all logic above
> succeeds): [thinking out loud]
> assertTrue(
>     actual.equals(expected) && expected.equals(actual),
>     String.format(
>         "All elements equal via iteration, but equals(Object) method
> failed%n\tActual class: %s%n\tExpected class: %s",
>         actual.getClass().getName(),
>         expected.getClass().getName());
>
> Even better would be to test "both directions", and report any strange
> results, e.g.,
> boolean actual_vs_expected = actual.equals(expected);
> boolean expected_vs_actual = actual.equals(expected);
> if (actual_vs_expected != expected_vs_actual) {
>     // report nice error message
> }
>
> As a guess, it seems the Collection<T> specialised form was written to
> provide nicer error reporting.  That is all good.  It is helpful in many
> cases.  I am asking for something a bit more.
>
> Further, after reviewing this email, I realise that implementing the
> Collection<T> interface (or any sub-interface), but adding additional data
> not accessible via iterator() is probably a Very Bad Idea.
> For example: AbstractList<T> (super class for ArrayList<T>) implements
> equals() by comparing iterators from both the lists.  This would violate the
> symmetric property of equals().
> All said, I would still like to know this bad scenario has happened between
> collections.  The bit above "if (actual_vs_expected != expected_vs_actual)"
> would catch exactly this violation of symmetric property.
>
> Please share your thoughts.
>
> Kind regards,
> Kevin Connor ARPE
> Hongkong
>
> --
> You received this message because you are subscribed to the Google Groups
> "testng-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> To post to this group, send email to [hidden email].
> Visit this group at http://groups.google.com/group/testng-dev.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Regards / Pozdrawiam
Tomek Kaczanowski
http://practicalunittesting.com

--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/testng-dev.
For more options, visit https://groups.google.com/groups/opt_out.