Re: class design: where to put debug purpose utility class?
On Jun 26, 7:51 pm, 123098...@gmail.com wrote:
Let's say I have the following class:
class foo {
public:
foo();
void addItem(int item);
private:
int* items;
};
I want to write a unit test program to test foo::addItem(), to do that
the test program needs to know the contents of foo::items.
No, the unit test program has to confirm only that addItem() did what
it was supposed to do (or more formally, that the functions's
"postcondition" has been fulfilled after the call). Moreover, testing
addItem()'s postconditions is done solely from a client's point of
view. A unit test has no special access to the internals of the
interface being tested - nor does it have any knowledge of the
inteface's implementation.
So in this example, a unit test would confirm that addItem() worked by
calling other -public- routines in foo's interface - that would have
beeen affected by the addItem() call. For example, if foo had a size()
method, a unit test would might call size() before calling addItem(),
save the result, then call adItem() and then call size() again, and
confirm that the size() of foo has increased by one.
So I can add one more public function to class foo:
int* getItems();
But suppose in my case, the client code of class foo does not need
getItems() at all, this function serves only for test in this case.
If the client does not need a getItems() method then there is no
reason to add one to foo's interface. A unit test should test only the
public routines an interface - and use only the public methods of the
interface (that is, the one available to all clients) to do so. A unit
test should not have special knowledge of the internals of the
interface's implementation.
After all, if there is no way for the client to tell whether addItem()
did anything or not, then there would be no reason for the client to
call addItem() in the first place. Because from the client's point of
view - whether addItem() is called or not - makes absolutely no
difference, so why bother calling addItem() at all?
So I am considering to have a separate class fooTest and this class is
a friend class of class foo so that it has an API to retrieve all
private data of foo.
Giving the test access to foo's private data would make the test
dependent on those implementation details - exactly what an unit test
must avoid. For one, if the unit test tests only the public interface,
then the programmer is free to replace the entire implementation of
"foo" without breaking (or having to rewrite ) the test. The unit test
can also confirm that any such refactoring has not changed foo's
behavior in any way that would affect clients of foo.
I believe this works, but I am wondering if there is better solution.
Basically my goals are:
1. I do not want the class to be bloated with a lot of API which only
serve for test purpose
There should not be any code added to foo's public API for unit
testing purposes.
2. I want the function class to be independent from test class
Yes, the unit test should be completely independent from the interface
being tested (in other words, the unit test should just be another
client of foo - and nothing more).
Greg