>
> > 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.
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.
It is a world of difference.
> 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.
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.
> 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 {} ).
> 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 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.
>
> please keep these highly fragile
>
why is it fragile?
> and debatable things
>
that's why I initiated this debate in the first place.
Peter
