[Pharo-users] [Pharo-dev] TestAsserter>>assertCollection:hasSameElements:

jtuchel at objektfabrik.de jtuchel at objektfabrik.de
Sun Oct 25 06:37:06 EDT 2015

Sorry guys, but today is my destructive day...

I think most of the assert:whatever: methods are a waste of time and 
energy and just pollute SUnit with lots of methods that are named with 
misleading or at best debatable names.


assert:equals:  it's just more typing than #= with no additional outcome

So, let's start by asking what the question really means. Does it mean 
that one collection is a subset of the other? What about ordering then? 
Does it mean both contain the same elements at the same position or just 
the fact that if they both were Sets contained the exact same elements. 
The question itself is not exact, so how could an answer possibly be?

Just a few weeks ago, we discussed something similar about the equality 
of two Collections. Endless discussions where people try convince others 
that their definition of equality and/or sameness is correct with no 

To me, something like assertCollection:hasSameElements: means asking for 
trouble, because each and every definition of what that may mean is 
debatable. It's unwanted syntactic sugar (actually it's more like rat 
poison than sugar).

So what we really need to do is find ways for SUnit to formulate exactly 
what we mean and use these as helpers in the execution of a simple 
assert:. And that is not by adding new variants of assert:
Adding more and more methods to TestAsserter only makes the frustration 
with such problems increase and people hat SUnit more and more.

So we need an extensible set of objects that, say, compare two 
collections and return true or false. These can be used in an assertion 
but also in domain code. We don't need more and more variations of assert:

So we could start by providing an abstract superclass for comparing 
collections based on more than just #= and #==. Then we can add 
subclasses for that which have a real intention revealing name like 

Thinking about it, I even think that it really is a stupid idea. Because 
chances are you need such a functionality in your domain code anyways 
(you'd hardly need a test for it otherwise), so you most likely 
implement the very same thing for exactly your purposes in your project. 
And since we always write such a beast with lots of tests, we have a 
reliable and debate-free way of what we really want SUnit to test for if 
we use that object or method in our tests in a simple assert:

All I am saying is: please keep these highly fragile and debatable 
things out of SUnit. It will cause  debates and frustration rather than 
improve people's opinion of SUNit and Unit testing. It is 
counter-productive and will do harm of all kinds.

Don't mistake the fact that some static languages had to add lots of 
assert: variations due to their static typing limitation with an 
anticipation that this might be a good idea. It's not.

Okay, I told you this is my destructive day, so you may shoot now ;-)


Am 24.10.15 um 22:14 schrieb Christophe Demarey:
> Hi Peter,
> Le 24 oct. 2015 à 20:36, Peter Uhnák a écrit :
>> bump? :)
>> On Tue, Sep 29, 2015 at 12:57 AM, Peter Uhnák <i.uhnak at gmail.com 
>> <mailto:i.uhnak at gmail.com>> wrote:
>>     How practical it is to do set-based comparison
>>     in TestAsserter>>assertCollection:hasSameElements: ?
>>     For example #(1 1 2) has same elements as #(1 2) which may make
>>     sense for sets, but not for bags.
>>     The main reason I was using it is that in tests the expected
>>     collection may be created by hand,
>>     which means it is very often an array #(...), { ... }, while
>>     models very often return OrderedCollections (at least in my case).
> I introduced #assertCollection:hasSameElements:  for this reason.
> The problem with using sets is that I do not expect that  #(1 1 2) has 
> same elements as #(1 2)
>>     So my question is --- how to compare collections irrespective of
>>     type, and possibly of order?
>>     A) always convert the actual collection toanArray
>>     B) change difference: behavior for non-sets (ton of work with
>>     catastrophic consequences)
>>     C) extend TAssertable with new methods like
>>     #assertElementsOf: actualCollection equals: expectedCollection
>>     #assertUnorderedElementsOf: actualCollection equals:
>>     expectedCollection
> This solution has my preference
>>     C.a) directly in Pharo/SUnit
> yes, for me, it is a very basic assertion that should be available as 
> default.
>>     C.b) in independend SUnit-Extensions repository/project
>>     C.c) just in my project
>>     D) stop discussing non-problems
>>     Thanks,
>>     Peter
> Christophe

Objektfabrik Joachim Tuchel          mailto:jtuchel at objektfabrik.de
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20151025/414ed84d/attachment.html>

More information about the Pharo-users mailing list