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

[jtuc...@objektfabrik.de]

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/" 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 

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

[jtuc...@objektfabrik.de]

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

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

[jtuc...@objektfabrik.de]

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

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?


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.


To me, something like assertCollection:hasSameElements: means asking for 
trouble, because each and every definition of what that may mean is 
debatable. It's unwanted syntactic sugar (actually it's more like rat 
poison than sugar).


So what we really need to do is find ways for SUnit to formulate exactly 
what we mean and use these as helpers in the execution of a simple 
assert:. And that is not by adding new variants of assert:
Adding more and more methods to TestAsserter only makes the frustration 
with such problems increase and people hat SUnit more and more.


So we need an extensible set of objects that, say, compare two 
collections and return true or false. These can be used in an assertion 
but also in domain code. We don't need more and more variations of assert:


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.


Thinking about it, I even think that it really is a stupid idea. Because 
chances are you need such a functionality in your domain code anyways 
(you'd hardly need a test for it otherwise), so you most likely 
implement the very same thing for exactly your purposes in your project. 
And since we always write such a beast with lots of tests, we have a 
reliable and debate-free way of what we really want SUnit to test for if 
we use that object or method in our tests in a simple assert:


All I am saying is: please keep these highly fragile and debatable 
things out of SUnit. It will cause  debates and frustration rather than 
improve people's opinion of SUNit and Unit testing. It is 
counter-productive and will do harm of all kinds.


Don't mistake the fact that some static languages had to add lots of 
assert: variations due to their static typing limitation with an 
anticipation that this might be a good idea. It's not.


Okay, I told you this is my destructive day, so you may shoot now ;-)


Joachim





Am 24.10.15 um 22:14 schrieb Christophe Demarey:

Hi Peter,

Le 24 oct. 2015 à 20:36, Peter Uhnák a écrit :


bump? :)

On Tue, Sep 29, 2015 at 12:57 AM, Peter Uhnák > wrote:


How practical it is to do set-based comparison
in TestAsserter>>assertCollection:hasSameElements: ?

For example #(1 1 2) has same elements as #(1 2) which may make
sense for sets, but not for bags.

The main reason I was using it is that in tests the expected
collection may be created by hand,
which means it is very often an array #(...), { ... }, while
models very often return OrderedCollections (at least in my case).




I introduced #assertCollection:hasSameElements:  for this reason.
The problem with using sets is that I do not expect that  #(1 1 2) has 
same elements as #(1 2)




So my question is --- how to compare collections irrespective of
type, and possibly of order?

A) always convert the actual collection toanArray

B) change difference: behavior for non-sets (ton of work with
catastrophic consequences)

C) extend TAssertable with new methods like

#assertElementsOf: actualCollection equals: expectedCollection
#assertUnorderedElementsOf: actualCollection equals:
expectedCollection



This solution has my preference


C.a) directly in Pharo/SUnit



yes, for me, it is a very basic assertion that should be available as 
default.



C.b) in independend SUnit-Extensions repository/project
C.c) just in my project

D) stop discussing non-problems

Thanks,
Peter




Christophe



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

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

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

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

> 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.
> 
> To me, something like assertCollection:hasSameElements: means asking for 
> trouble, because each and every definition of what that may mean is 
> debatable. It's unwanted syntactic sugar (actually it's more like rat poison 
> than sugar).
> 
> So what we really need to do is find ways for SUnit to formulate exactly what 
> we mean and use these as helpers in the execution of a simple assert:. And 
> that is not by adding new variants of assert:
> Adding more and more methods to TestAsserter only makes the frustration with 
> such problems increase and people hat SUnit more and more.
> 
> So we need an extensible set of objects that, say, compare two collections 
> and return true or false. These can be used in an assertion but also in 
> domain code. We don't need more and more variations of assert:
> 
> 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.
> 
> Thinking about it, I even think that it really is a stupid idea. Because 
> chances are you need such a functionality in your domain code anyways (you'd 
> hardly need a test for it otherwise), so you most likely implement the very 
> same thing for exactly your purposes in your project. And since we always 
> write such a beast with lots of tests, we have a reliable and debate-free way 
> of what we really want SUnit to test for if we use that object or method in 
> our tests in a simple assert:
> 
> All I am saying is: please keep these highly fragile and debatable things out 
> of SUnit. It will cause  debates and frustration rather than improve people's 
> opinion of SUNit and Unit testing. It is counter-productive and will do harm 
> of all kinds.
> 
> Don't mistake the fact that some static languages had to add lots of assert: 
> variations due to their static typing limitation with an anticipation that 
> this might be a good idea. It's not.
> 
> Okay, I told you this is my destructive day, so you may shoot now ;-)
> 
> 
> Joachim
> 
> 
> 
> 
> 
> Am 24.10.15 um 22:14 schrieb Christophe Demarey:
>> Hi Peter,
>> 
>> Le 24 oct. 2015 à 20:36, Peter Uhnák a écrit :
>> 
>>> bump? :)
>>> 
>>> On Tue, Sep 29, 2015 at 12:57 AM, Peter Uhnák  wrote:
>>> How practical it is to do set-based comparison in 
>>> TestAsserter>>assertCollection:hasSameElements: ?
>>> 
>>> For example #(1 1 2) has same elements as #(1 2) which may make sense for 
>>> sets, but not for bags.
>>> 
>>> The main reason I was using it is that in tests the expected collection may 
>>> be created by hand,
>>> which means it is very often an array #(...), { ... }, while models very 
>>> often return OrderedCollections (at least in my case).
>> 
>> 
>> I introduced #assertCollection:hasSameElements:  for this reason.
>> The problem with using sets is that I do not expect that  #(1 1 2) has same 
>> elements as #(1 2)
>> 
>>> 
>>> So my question is --- how to compare collections irrespective of type, and 
>>> possibly of order?
>>> 
>>> A) always convert the actual collection toanArray
>>> 
>>> B) change difference: behavior for non-sets (ton of work with catastrophic 
>>> consequences)
>>> 
>>> C) extend TAssertable with new methods like 
>>> 
>>> #assertElementsOf: actualCollection equals: expectedCollection
>>> #assertUnorderedElementsOf: actualCollection equals: expectedCollection
>> 
>> This solution has my preference
>> 
>>> C.a) directly in 

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

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

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/" 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

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

[Christophe Demarey]

Hi Peter,

Le 24 oct. 2015 à 20:36, Peter Uhnák a écrit :

> bump? :)
> 
> On Tue, Sep 29, 2015 at 12:57 AM, Peter Uhnák  wrote:
> How practical it is to do set-based comparison in 
> TestAsserter>>assertCollection:hasSameElements: ?
> 
> For example #(1 1 2) has same elements as #(1 2) which may make sense for 
> sets, but not for bags.
> 
> The main reason I was using it is that in tests the expected collection may 
> be created by hand,
> which means it is very often an array #(...), { ... }, while models very 
> often return OrderedCollections (at least in my case).


I introduced #assertCollection:hasSameElements:  for this reason.
The problem with using sets is that I do not expect that  #(1 1 2) has same 
elements as #(1 2)

> 
> So my question is --- how to compare collections irrespective of type, and 
> possibly of order?
> 
> A) always convert the actual collection toanArray
> 
> B) change difference: behavior for non-sets (ton of work with catastrophic 
> consequences)
> 
> C) extend TAssertable with new methods like 
> 
> #assertElementsOf: actualCollection equals: expectedCollection
> #assertUnorderedElementsOf: actualCollection equals: expectedCollection

This solution has my preference

> C.a) directly in Pharo/SUnit

yes, for me, it is a very basic assertion that should be available as default.

> C.b) in independend SUnit-Extensions repository/project
> C.c) just in my project
> 
> D) stop discussing non-problems
> 
> Thanks,
> Peter
> 

Christophe

smime.p7s
Description: S/MIME cryptographic signature