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.uh...@gmail.com
<mailto:i.uh...@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:jtuc...@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
