Re: Dos and don'ts in C++ unit testing?
Dave Steffen wrote:
[...]
We had a discussion a while back on the Boost users list about this
issue, which can be called the "How do I unit test private methods"
issue. I'll summarize results as:
A) Black Box Testing: Don't test private methods or members at all.
Test only the public interface. Your classes have a specified
interface with specified behaviors. Test that and don't worry about
the rest.
This is essential if the tests are to be used for regression
testing. Anything which isn't part of the specified interface
may change from one version to the next. If you test it, you'll
have problems when the test suite automatically runs.
(Generally speaking, checking in a component will cause the unit
tests to be automatically executed. If they fail, for any
reason, the new version of the component will not be visible to
other users; depending on the system, the check-in itself will
fail.)
B) White Box Testing: poke and prod at the object's guts, e.g. private
members and methods. The question here is how to get access to the
object's guts.
Note that in some cases black box testing is appropriate, and in some
cases white box testing is appropriate. One isn't better than the
other, they're for different kinds of testing.
White box testing cannot be used for regression tests, which
practically means, for any formallized test procedure. I've
never found them of much use anywhere, but it's possible that
others find them useful for debugging and such. If that's the
case, access to the private parts isn't a problem; most
debuggers ignore access protection completely.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]