GitLab

Hi Anthony,

for the purpose of inherit sidekit.StatServer (e.g., for defining stat2 or other attributes), I introduced a nested template function called by accumulate_stats, which can be altered by labs using sidekit, without touching the original sidekit. In order to not call this template function on large-scale tests where only the original sidekit is of interest, I introduced a flag variable before the for-loop, which determines, whether or not the nested template function was inherited, and thus whether or not it may need to be called.

Regarding the Key file, I added Matlab file format support.

In order to sanity-check my changes (which apparently was more necessary than I hoped ;-) ), I started a unittest folder, in which all unittests could be put. In the "naming convention" I went for an easy way, i.e. test[subpackage][classfilename].py - an init.py contains two lists of either typical sidekit class functions and unittest class functions. These are created for the purpose of sanity-checking the unittest implementations ... maybe a newly introduced method was missed to be added to the unittest of the class, and maybe the a deprecated method was dropped, but still is tested within the depending unittest class. Please have a look on the tearDownClass functions of the unittests for the key and the statserver classes. Due to time limitations, I just concerned the functions, which I have touched during the process - all other functions I augmented with the decoration"@skip("not-yet implemented UnitTest") - hope this provides a neat basis for your unittests to come.

In the unittest for the StatServer, I demonstrated on a minimal example how inheritance augmenting the accumulate_stat could look like. My implementation with this "LatticeStatServer" went out much more detailed than I assumed in the beginning (until not published I won't put it inside sidekit, the approach is merely put into the world and barely examined). But: the advantages of this design are that a) sidekit is not touched on expansions by different labs (comparability & LGPL concerns), b) sidekit code can be reused without rewriting it, avoiding point of failures. Also, I added some read/write & merge handle examples. Regarding merge(), I externalized the pre-computation of meta information, since this is also necessary for inherited classes - avoiding redundant code on inheritance. During file-I/O unittests, I used tempfiles, thus each unittest case call a setUp & tearDown where a list of tempfiles is initialized, and cleaned up afterwards.

In the unittest for the Key, I'm just looking for whether or not HDF5 datasets / groups / datasets in groups exist, according to the depending file format convention (sidekit/Matlab).

Regarding the implemented unittests, I don't claim them to be exhaustive. It is a starting point to check basic functionality. If bugs are caused, the unittests need to be adapted as well. Also, please feel free to implement the skipped functions (or maybe a student assistant can be motivated for this task).

Best, Andreas