hey:
Sam Couter wrote:
>Karl Fogel <kfogel@newton.ch.collab.net> wrote:
>
>
>>Ah, understood. But imho, any function is eligible to be tested;
>>there's no reason for the fs api to treat testing callers differently
>>from other callers. There isn't any such thing as "test aware". If
>>it's there, it can be tested :-).
>>
>>
>
>Black-box testing requires no knowledge of, or access to, the internals
>of an implementation.
>
>But what about white-box testing? It's sometimes easier and more
>effective for the test to know something of the internals of an
>implementation, and to sanity check those internals during testing.
>
>It's not unusual for a library or module to expose certain internals in
>order for them to be tested.
>
Yes, I've done this in Java code before.
So this was my line of thinking.
However, this is C and the functions are exposed to the other code
already via internal header files. The functions have the telling "__"
in their name. Which can be considered semi-private, friend like or
package protected. In short callers assume some contextual
responsibility. The test stuff includes the headers intended (so I
thought) for internal libsvn_fs use. So the test code assumes that
responsibility. I was proposing formalizing something which is already
exposed. My hope was that I could force/encourge new FS developers to
at least meet the needs of a formal test API. Thus allowing certain
tests to be re-used.
Karls take is that every thing is game to be tested. Right Karl?
If a test case becomes brittle and breaks as a result of code changes we
have three choices:
1. fix it.
2. split it out to be FS type specific. Perhaps two tests will emerge.
3. delete the test.
Am I hearing you Karl?
The problem is that I haven't dug through the test code enough to make
any specific point:-) Bad move gat ... whaap
So in the words of Emily Latella ...... never mind.
Sorry,
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 29 03:45:41 2002