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

jtuchel at objektfabrik.de jtuchel at objektfabrik.de
Mon Oct 26 04:38:23 EDT 2015


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 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).
>
>     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 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/20151026/666742bf/attachment.html>


More information about the Pharo-users mailing list