Richard Liang wrote:
Geir Magnusson Jr wrote:
George Harley wrote:
I don't want an argument any more than the next person but ... I
completely agree with the above statement. If you can't test code by
going through the public API then how will the users ever get to
exercise it in the "real world" ?
The key is that we aren't suggesting we don't test code by the public
API - we have to do that. But rather, we need to ALSO test the
internals w/o going through the public API....
Hello Geir,
But rather, we need to ALSO test the internals w/o going through the
public API....
Why? IMHO, it's easier to write test cases through public API. And the
internals may possibly change, so if we write test cases directly for
the internals, our test cases will not be stable.
I don't think it's easier to write test cases for internals though a
public API, because you can call the internal methods directly to see if
they do as they promise, where it's not so easy to always have the same
thing happen through an indirect public API.
Also, wrt things breaking..... yes, tests that ensure that something
works as expected will need to change if the expectation changes.
That also is exactly what you want, right? To know if you broke a
'internal contract' in a class?
geir
- Re: Unit testing revisited Geir Magnusson Jr
-