--- In squeak at yahoogroups.com, "Lukas Renggli" <renggli at ...> wrote:
>
> > I think that Diego is saying that it is better not to test the
> > implementation but the behavior of an object. If the implementation
> > changes and you have implementation tests, you will have to change
> > them. On the other hand, if you only test behavior and you change the
> > implementation you should not change the tests.
> 
> But this is the same, if you change the behavior or interface, you
> have to adapt the tests as well, so this does not count ;-)
> 

Ha, ha, this is a good one... but only if you take it out of context...
Of course that if B depends on A an A changes, then B will have to
change, that is not the issue. I think the issue here is: "What's more
important, implementation or behavior?" and I beleive the answer is
behavior. Implementation can change many times but the
responsibilities of an object, its essence, should change less that
its implementation... (I'm not saying that is always like this, but
that's the idea...)
If I have tests based on behavior, then I can reuse them for different
implementations, for example, a Stack could be implemented with a
List, with an Array, etc., there could even be the two
implementations, but I could use the same tests...
Anyway, having said this, I guess I can answers your "so this does not
count ;-)" with a "so this does not count ;-)" ;-) (hey, just kidding,
don't get mad!).

> > I understand that you would want to see that your implementation is
> > right, but is not enough to test the behavior? what implementation
> > mistake couldn't you find testing the behavior?
> 
> You are probably right for most cases.
> 
> How do you test class invariants in your test-cases, without exposing
> the internal state of the object?

Well, I beleive that an object's invariant is based on its behavior,
not its implementation. For example, in a CircularList the last and
first elements are linked (if there are elements of course). That's
the invariant no matter if the CircularList uses a DoubleLinkedList,
an OrderedCollection or whatever structure you want to use to
implement the circular list.
I don't think you have to expose the internal state of an object to
test its invariant... The idea of invariant, as I understand it, it is
tied to the concept itself and if you want to test the invariant, that
should happend all the time something changes in the instance of that
concept. That's what Eiffel does, but in Eiffel you write the
invariant as part of the class not as a separate test.

[snip]
> > We have talked with Diego many times about annotations and our opinion
> > is that annotations are a tool that do not follow the idea of having
> > only "objects and messages". It is sintax sugar that makes the
> > language more difficult to use. It is a matter of taste and I don't
> > like sugar :-)... (For sure you have discuss this on the list many
> > times...)
> 
> - An annotation is an object, as everything is.
> 
> - An annotation is a message(-send), you can send it to any object and
> have behavior and/or a return objects as an effect.

I have to admit that I have not read about annotations, just saw a few
examples, but I'd like you to think about this:
1) When I see an annotation I don't see an object, neither a message
not a message send, I just see "<anAnnotation>".
2) This means that I need to learn something new that is not about
objects and messages (at least explicitly) but about sintax.
This may be a good price to pay, but only if this new tool gives me
something it is hard to do in other ways.

When I see an annotation I see a "tag" (an this is personal, maybe if
I read more about them I'll see other things), wich remembers me and
transports me to the "relational paradigm", where everytime you need
to "tag" something you just create a new "field" on the "row". 
But, what is the essence of doing this?, the essence is to create a
categorization. In the case of annotations, to categorize a method
using different "tags". 
Well, I beleive categorization can be achieved in a much simple and
flexible way using sets (I mean set in the abstract way) which in the
"relational paradigm" would mean to create a new table, and in the
case of tests using SUnit, to create different suites.
Forgive my ignorance, but how would you categorize a test of beeing,
let's say, an architecture test and an integration test with
annotations? I want to be able to run only architecture tests, or
integration tests, or both or neither.
I cant think of two ways of anotating:
1)
aClass>>test1
   <architectureTest>
   <integrationTest>
   ... the test

2)
aClass>>test1
   <architectureTest>
   <integrationTest>
   <architectureTestAndIntegrationTest>
   ... the test

But I don't kwnow how to obtain which ones are architecture tests, 
etc.
Using sets and suites, it is simple:

Set architectureTests := Set with: aClass>>test1 with: ...
Set integrationTests := Set with: aClass>>test1 with: ...
Set archtectureAndIntegrationTests := architectureTests union:
integrationTests.

architectureTestSuite := (TestSuite named:..) addTests: architectureTests.
integrationTestSuite := (TestSuite named:..) addTests: integrationTests.
etc.

If I need to change the categorization, I change the objects (the
sets), not a method, and the info about the categories is in one
place, not spread all over.

Bye,
Hernan.