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

Sven Van Caekenberghe sven at stfx.eu
Sun Oct 25 06:45:40 EDT 2015


> On 25 Oct 2015, at 11:37, jtuchel at 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.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).
>> 
>> 
>> 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: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
> 
> 





More information about the Pharo-users mailing list