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.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).
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: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
