Improve unit testing of epdf

[smidl]

At present, epdfs are tested independently and randomly in files: testEpdf, testSmp, emix_test, enorm_test, egiw_test

Most of the tests for offsprings of epdf can be unified into a common structure that can be parameterized via libconfig by a set of .cfg files.

The main test would read a cfg file, that would contain:

epdf = {class = "epdf_offspring",...}; //UI for the epdf to test
mean = [...]; //theoretical mean
covariance = (rows,cols, data); //theoretical covariance matrix
support = ...; // significant part of its support on which to integrate
== optionally (numbers below are defaults) ===
nbins = [100]; //number of bins for numerical integration
nsamples = 1000; // number of samples to generate
=== optionally ====
marginal = {class="epdf",...}; //theoretical marginal
conditional = {class"mpdf", ...}; //theoretical conditional

The code itself would:

• build the pdf
• compare if theoretical moments agree with outputs of mean() and variance()
• perform numerical integration on given support and check if it is close to 1. (done e.g. in egiw.cpp)
• generate nsamples samples using sample() and check if their expected value is close (done in testSmp.cpp)
• if theoretical marginal and conditional densities are given, compare them with output of marginal() and condition()

Is this reasonable? My doubts are with the fact that some private functions of the class will not be tested in this setup - perhaps breaking the idea of unit-testing.

An alternative would be to design a generic functions for those test in a file epdf_common.h and include it in all unittests of classes.

Opinions?

[vbarta]

Well, I don't think it's reasonable to expect testing, even unit testing, to test _everything_ - the library isn't going to control a nuclear reactor, right? We can have some approaches to testcase generation (for example adding a testcase for a specific bug before fixing it) and implement what falls out of them. Testing each function in turn isn't really an "alternative" to testing the mathematical invariants - they're just different ways to come up with tests, which we should prioritize (i.e. by saying that testing mathematical invariants is more important than maximizing coverage) rather than just select one...

[smidl]

What is the status of this ticket? Can I close it? Or is there any input needed form my side?

[vbarta]

I think it's finished. Configurable tests have been implemented (as documented in unit_testing.dox) and tests from testEpdf, testSmp, emix_test, enorm_test and egiw_test were moved to testsuite - either as configurabe tests, or as hand-written special cases.