Re: c++ class design: where to put debug purpose utility class?
On Jun 30, 8:20 pm, 123098...@gmail.com wrote:
Here is more realistic capture of my problem, the original
post is over-simplified, but I do learn a lot from your guys'
discussion,
class repo {
public:
repo();
/**
* Add one repo search path, if the path satisfies all the
requirements, this path will be stored internally.
*
* @returns 0 if succeeds
*/
int addSearchPath(string path);
/**
* Retrieve all the item from all the search paths
*/
std::vector<item> getAllItems();
private:
vector<string> pathList;
};
Given the above class, my unit test is to cover
addSearchPath(), so I can do either of the followings:
1. Just use the 2 public functions since they are the real API that
customer code will use.
2. Unit test code accesses the private data directly to verify
addSearchPath().
Or 3: both. There are many different levels of testing, and it
may be useful for development purposes to "see" the internals.
(Why not specify some logging output? That way, the added code
might be useful in the final application as well.)
I guess James Kanze would suggest #1,
At some point or another, you need #1. You can't release the
code without it.
but for my case I lean to #2.
The reason is unit test using #1 requires quite a bit setup
for class item while this unit test just want to test
addSearchPath() does cover all the requirements for a valid
search path, so #1 seems to me too much academic.
#2 doesn't really cover all of the requirements, if the
requirements include actually using the added value in some way,
so that it affects the return value of getAllItems(). And if
it's that much work to set it up, then you need to get a better
test harness.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34