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.

Examples:

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

assertCollection:hasSameElements:
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 outcome.

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 CollectionHasExactlyTheSameElementsAsAnotherAtTheSamePosition.

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 ;-)


Joachim





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@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@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