Sorry for bringing this thread back :) I've just found an example when access to internals helps avoiding test modification.
I'm developing an implementation using some internal buffer of length like static int BUF_LENGTH = 256; To reduce JNI overhead it accumulates data and passes it into native function when the buffer is full. Buffer length affects performance and might be changed later. And I have tests that verify how my implementation works when input size is close to the buffer size. Currently I do something like check(BUF_LENGTH - 1); check(BUF_LENGTH ); check(BUF_LENGTH + 1); check(BUF_LENGTH *2); And the 'check' method tests API only. If later I decide to change internal buffer size I'll not have to change the test. But if I had hardcoded constants in the test then I could later change buf size forgetting to change the test and leaving boundary conditions untested. Thanks, Mikhail 2006/3/27, Mikhail Loenko <[EMAIL PROTECTED]>: > Hi Richard, > > > 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. > > One of examples might be: to test something trough public API > you need a test of 1000 lines of code, but if you can access internals, > 10 lines is enough > > Thanks, > Mikhail >
