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