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