SUnit: Skipping tests?

Lukas Renggli renggli at gmail.com
Wed Mar 29 15:13:42 UTC 2006


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

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

> If there is an implementation error, for sure it will pop up in a
> behavior test. If not, I beleive that you are not covering a 100 % of
> your code.

Again, you are probably right, but it might be not that obvious and/or
only appear later on.

> Here at Mercap, we have more than 7000 unit tests and we do not test
> implementation at all and when we found a bug, it was because there
> were not "behavior" test to cover that situation.

Sure, I do the same in Magritte and Pier with almost 3000 tests.

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

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch



More information about the Squeak-dev mailing list