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

jtuchel at objektfabrik.de jtuchel at objektfabrik.de
Mon Oct 26 02:54:18 EDT 2015

Hi Sven,

Am 25.10.15 um 11:45 schrieb Sven Van Caekenberghe:
>> 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'.

I really love the code you write and admire your tools. So I am glad I 
didn't respond to your comment right away. Peter's comment on this 
thread helped me understand what you were talking about ;-) Because this 
kind of comment is the least expected reaction I could possibly get. 
OTOH it seems like a good explanation for why SUnit is being misused the 
way it is.
What you basically are saying is that people had no better idea to get 
better error descriptions than to add more and more useless and misnamed 
assertion methods. I know you are a really good developer so I guess you 
are saying this because we are lazy people by design, not because you 
think the way to achieve the goal is a good approach, right?

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

are you trying to be sarcastic or do you really agree? If your example 
is a way of showing me that the code needed to be absolutely explicit 
about what you want is hard to read, then it sure is a good one. But it 
is not an excuse for badly named methods that save typing...
I didn't say it is a bad thing to provide shorter method names for 
complex facts. I said it is a bad thing to name them wrong or 
misleadingly. Because this will lead to frustration. If you name a 
method with the word "Collection" in it and implement it in a way that 
is only valid for Sets, this is a clear misnomer, isn't it?

There's nothing wrong in writing your own extensions for SUnit, but not 
every method that you think is handy is a good candidate for the base 
framework, even if it's just the Pharo-fork of it.

More as a response to Peter's comment...


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