Am 25.10.15 um 16:33 schrieb Peter Uhn��k:
> assert:equals:�� it's just more typing than #= with no additional outcome

I also disagree, but that may be also because maybe we write tests for different purpse.
If you write tests just to test your code, then whatever... I don't do that so I can't comment on that.

However if you do TDD, then tests are to provide feedback, and from that perspective you want to see immediately what is the difference. If I see that the assertion failed I have to start digging to find out what is the difference, which is extra work and bad from feedback perspective. If I instead immediately see what I need to see it allows me to faster deduce the source of the problem and resolve it.

I'm sorry, but what you are saying doesn't make any sense. Even if I "only" want to test code (which is exactly what you do in TDD, btw.), I need good feedback.
That is, btw., the reason why I suggested an extension to SUnit a few years ago that would help keep test results in a collection for use in CI environments.

So I agree there is the problem of short and precise ways of giving precise and helpful feedback in SUnit. But solving this by adding more and more variants of assert: to the framework, just to give nicer error strings is like healing a headache by decapitating the patient.

What is needed is some way to make providing feedback easier and friendlier, and we should think about ways to achieve that. Adding lots of sloppily-defined assertion methods is just the wrong solution.

We could think about subclassing TestFailure and a way to hand information to the TestFailure so that a nice String can be produced. Like a method like cull: that adds arguments' printString representation into the failure description.

And this is actually quite generic idea... imagine that you are filling a web form and when you click "submit" the website tells you "the form is invalid" and nothing else; that is not helpful at all.
If it instead tells you "The date must be in format MM/DD/YYYY" and highlights the incriminating field that I immediately can see the problem and can fix it quickly.

So the different #assert:whatever: provide context for the assertion to be able to get more valuable feedback.
Please step back for a second and think again: these are two very different things. The job of an Assertion is to make a problem visible. The representation of the problem is something else, even if these are closely related. This is object thinking lesson #2 or so.


It is a world of difference.

I agree. Good and exact feedback is at least as important as finding a problem. Because knowing there is a problem without understanding the problem is not enough. But that does not support the theory of "more assertion variants make our life so much easier". It only says we need a way to provide good feedback that is short and precise enough to not be ignored to our laziness.

But: adding more and more misnamed and misleading assertion methods makes the use of SUnit frustrating and will make it obsolete over time. If I have to hunt for design problems in SUnit because it assumes something to be wrong even though my understanding of waht I tested is different, I lose way more time than I am ready to accept. This doesn't happen to me often. If finding that I misunderstood an assertion method means I lost a few hours, the best thing that may happen is that I never use that method again. In the worst case, I decide I think SUnit is useless for me. That would be really bad, don't you think?

��> 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?

There is no question about this method, since this is implemented in code there is nothing ambiguous. This method effectively converts both arguments to sets and compares them like that.

Sorry to say that, but this is ambiguity by design: you define hasSameElements: as "both result in the same Set". So the name of this assertion method is a great example of bad naming, IMO.

The question is whether such thing is useful for non-sets, and there are definitely cases where such assertion is not appropriate (when you want to ensure that there are specific items or specific positions), that's why I suggested asserts specifically for that.
This is just nonsense. You name a method after a general collection class and try to tell me that it doesn't matter that it is only suitable for Sets and that is okay?

��
self assert: result asOrderedCollection asSortedCollection equals: (1 to: 10) asOrderedCollection

This is what I usually do now (although I convert to Array, not OrderedCollection, because the expected one is usually created by hand with #() or {} ).

I don't really care. If what you try t say is that the testing code can be ugly and long, then I agree. If you need tests like this very often and want something to make this easier, I understand and agree that some additions to SUnit can be helpful. But the way this has been tried so far seems completely wrong to me.

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

I don't see a problem with that because collections truly can have different equalities based on the context and their purpose. And while you can call this rat poison, it effectively tells what kind of behavior you expect from the collections, which seems ok.
So what, again, was the point of naming a method after a general Collection class and use a question that is very unspecific? A Collection has the same elements as another does not necessarily mean they both result in the same set. Can we agree on that? All the question asks if all Elements in Collection A can also be found in Collection B. The method name states nothing more than that.

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

well this one specifically is quite regular array comparison, questions are more about the other cases (without order, etc...). And I don't see why new class instead of a selector somehow solves this.
This is a misconception we also discussed in this other discussion. It simply isn't true. And even if it was true, it still wouldn't match with the chosen method name.

My point here is that a general purpose framework like SUnit should be free of such debatable things. SUnit has to be reliable and understandable.
There is nothing wrong with providing some "plugins" for problems like Collections that make life easier.
It would be desirable to have more control over SUnit's feedback with little typing.

But there is a lot that's wrong in polluting a general purpose framework like SUnit with unclear method names that are misleading, just plain wrong or debatable.

So we are discussing existing, real problems that exist in SUnit, and we are discussing about one of the possible ways to make SUnit friendlier that - in my opinion - is counter-productive.


��

please keep these highly fragile
why is it fragile?
Because my misunderstanding of what the author of assertCollection:hasSameElementsAs: thought the question means can cause me a hunt for bugs in his misnaming rather than my code. I may throw SUnit into the corner or just not trust in it. That's fragile, not agile.


��
and debatable things
��
that's why I initiated this debate in the first place.
Which is a good thing and I hope I could explain exactly enough why I think the addition of more and more assert: variations for the sake of better failure texts is the wrong path.

We should look for better, more precise ways to achieve what is needed. One step, IMO, is to agree on the fact that formulating an assertion and providing a helpful failure text are two strongly-related, but separate concerns. So a redesign of SUnit should be based on the question of how we can extend the feedback providing side of SUnit, and not on the question of what else people might be testing for and what the resulting text should be looking like and then find the best possible assertion method name based on that.

By writing this last sentence, I found another argument: not only teh new assertion method name could be misleading and debatable, but also the failure text you provide in the SUNit code base. This adds a third level of problems. What if your failure text was just "Not all Elements of $A are in $B" - does it match your implementation? I think it matches the method name, but not your implementation...


Nuff said,


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