@Peter: usually it is true to avoid testing private members, but for the sake of preventing a subsequent refactor of public API from creating side effects on private members, we need to create test cases with the purpose of fixing invariant in our classes. Also if you look at it in different manner, private members are part of the logic of the classes, which means not testing them could create logic bugs (what i call smart bugs) and refactoring them into public member would expose a lot of the guts of the implementation.
I used to test private members by checking their effects on public members (transitive side effects), but i run into a lot of cases where you cannot pin point the effect of a private member if the public member depends on many of them.
@Arthur O'Dwyer : ' Namespaces, unlike classes, are open.' very true, it would be a great idea if a friended namespace will be like an anonymous namespace, i.e. static to the translation unit it was defined in. expl:
friend namespace XYZ {}; // the friend keyword changes this namespace into a "static" namespace if we can say that!
class toBeTested
{
using namespace XYZ;
}
@Ville Voutilainen : adding an #ifdef preprocessor condition, adds to the maintainability of the class, and convey the meaning that testabilty is optional tho test development is almost mandatory in software building.
My motivation about this proposal is to:
- unrestrict the way we test our classes,
- keep implementation details hidden if they should be hidden,
- avoid dogmas of "how to use" or "not to use".
- unleash creativity (I'm pretty sure someone will find an interesting way to use this feature other than its intended use)
- and for projects which didn't implement testing from the beginning, they just have to create a friend namespace with functions that shadows the class API, and test the members of that friend namespace, one API at a time.
please advise.
Nadir