Re: Testing : Best practices?
On 12 Jul, 13:56, Keith H Duggar <dug...@alum.mit.edu> wrote:
On Jul 2, 9:50 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
I am using Boost.Test to write test suites for my programs.
In order to make my programs testable, I have adopted a tendency
to write lots of free functions where I earlier would have written
private members of classes.
Can you please provide a concrete example of what you mean? That
can be interpreted in so many ways so clarification would help.
I have one class that estimates where to best set a
threshold of a bimodal histogram:
class BimodalHistogramThreshold{
public:
size_t operator()(std::vector<double> h);
};
The idea is to use the thing as a function object.
The implementation relies on a number of primitive
operations, that I would prefer to keep as private
methods to the class:
size_t BimodalHistogramThreshold::operator()(... h)
{
normalize(h);
double a,b;
size_t c,d;
initializeParameters(a,b,c,d);
for (size_t i = 0; i< h.size(); ++i)
// no iterators because I use the index i in
// computations inside the routine
{
denormalize(a);
denormalize(b);
doSomeUsefulStuff(a,b,c,d,i,h[i]);
normalize(a);
normalize(b);
update(c);
update(d);
}
return c;
}
The inner workings of these types of functions are
way too detailed to test only at the public interface
level. I *need* to test all these different methods,
or I will not know if the algorithm works.
I *want* to keep the methods private to the class,
since they use names that are generally relevant
(de/normalize,initalize,update,...), but are actually
limited to the specific context of this class.
As of today, all the functions above are free functions
that are defined in the namespace MyNamespace. What
names of variables are concerned, I always write a
companion document when I implement these types of things.
Whenever I research an algorithm, I write up a technical
note in LaTeX, to ensure that I understand all the details,
get a coherent presentation with respect to notation,
variable names etc, if I use several sources, and so on.
While the variable names make no sense when the code
fragment is seen in isolation as above, the key is to
use exactly the same names in th eprogram as in the
companion technical note, or I am quickly lost. I wrap
my mind around the problem by writing the technical note.
The technical note represents my view of the algorithm,
so the C++ program has to mirror the technical note, both
in algorithms and in variable names.
All of this would work quite nicely, if I just could
manage to BOTH keep all these private to the class,
AND find a way to test them.
Rune
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]