> On 25 Oct 2015, at 11:37, jtuc...@objektfabrik.de wrote:
>
> 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
I disagree: it does make a real difference, it gives a much better error
message, like 'got $A but expected $X', instead of 'something failed'.
> 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?
I agree: it helps little. It is much clearer to write something like, for
example,
self assert: result asOrderedCollection asSortedCollection equals: (1 to: 10)
asOrderedCollection
because then you are very explicit about the test.
> 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> 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
>
>
