Mikhail Loenko wrote:
Sorry for bringing this thread back :)
Congratulations, Mikhail .
This is a great thread, indeed :-)
For the following example, I do recommend not to use BUF_LENGTH in check
method. Just imagining the situation that you wan to set BUF_LENGTH as
256, but occasionally set it as 255. The "check" will not find this defect.
IMHO, we shall try to test our code from our customers' perspective.
That is, we shall write test cases through the APIs which our customers
possibly use. But as you know, testing is always **risk-based**. If you
have good reason to write test cases through some internal APIs which
our customers will never use or cannot use, just do it. :-)
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
--
Richard Liang
China Software Development Lab, IBM
