Re: c++ class design: where to put debug purpose utility class?
On Jul 1, 5:08 am, S Perryman <q...@q.com> wrote:
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().
I guess James Kanze would suggest #1, 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 serves my purpose very well and I do not want to add more API to
return the internal private data, I will use #define private public
trick.
Please throw your bricks.
#3 add a getPaths op.
Then you can define a post-condition for the addSearchPath op.
Steve, that was an incredibly naive answer. The post-condition to
addSearchPath is, and should be, the effect it has on getAllItems.
Adding a getPaths function, or as others have suggested, just making
pathList public to the testing harness, fails to make that post-
condition testable.
The tests the OP needs are something like:
repo r;
int result = r.addPath( "badpath" );
assert( result != 0 );
assert( r.getAllItems().size() == 0 );
---
repo r;
int result = r.addPath( "goodpath" );
assert( result == 0 );
assert( r.getAllItems().size() == expectedSize );
// examine the items in the container to make sure they are
// the expected ones.
---
etc...
The fact that he claims that such tests are difficult because it
"requires quite a bit of setup for class item" suggests to me that his
'item' abstraction is ill-defined, and or he needs another abstraction
"Path".