Hi Sven, Am 25.10.15 um 11:45 schrieb Sven Van Caekenberghe:
On 25 Oct 2015, at 11:37, jtuchel@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:jtuchel@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