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ée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34