Hi Peter,

I just realize it is probably best to return to your initial post in order to not drift into D) ;-)

Am 24.10.15 um 20:36 schrieb Peter Uhn��k:
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).

So my question is --- how to compare collections irrespective of type, and possibly of order?

A) always convert the actual collection toanArray

I don't think it is a good idea to provide tests fro general Collections that first convert it to some specialized Collection class. There may be nothing wrong with doing so, but it always depends on what exactly you want to test for. If converting to an Array is part of that test, the test is specialized and not for Collections in general.
Seems to be an indication that your test is not a general Test on Collections...

B) change difference: behavior for non-sets (ton of work with catastrophic consequences)

You name it ;-)
C) extend TAssertable with new methods like��

#assertElementsOf: actualCollection equals: expectedCollection
#assertUnorderedElementsOf: actualCollection equals: expectedCollection

These names (I know, they are just examples, so I don't pick on them specifically) are always open for interpretation.

C.a) directly in Pharo/SUnit
No. For several reasons:
* The whole discussione we're having on this
* SUnit is a framework that is cross-platform. You can never be completely sure that a certain method on a Collection class which is not in the ANSI standard gives you the same results on another Smalltalk

C.b) in independend SUnit-Extensions repository/project
A much better approach. But then we have a portability problem if things like extensions and method overrides come into play. So this requires architectural changes in SUnit to enable a plugin mechanism. That, btw, would be a great thing!

C.c) just in my project
This should surely be a starting point to stabilize things. If we had plugins, it would be easy to publish your stuf as plugin at any time.


D) stop discussing non-problems
If you mean others think you should just shut up and you should just do it for yourself, then I think it is not a good option. I am quite sure your question shows that there is a problem with SUnit. Be it with Collections or any other area. SUnit started as something quick and dirty and thus is not perfect for many situations. We should look for patterns and solutions. I would definitely disagree if you suggest people might think your questions are a non-problem!


Joachim

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