Hi Fernando, I think if we're to proceed with the idea, we'd better design some tests first for a number of superclasses to see whether this would be better than the normal. In theory, I think this should be useful, as we test how complaint each subclass with the superclass interface. But when I tried writing generic tests for the "Machine" superclass, I had to do a lot of specializations for special cases, which made me question the efficacy of this method.
About GSoC 2020, I would like to participate, but I might not be able to find the time to do it as a student. We'll see. Also likewise, sorry for the delayed response, just finished term exams. Thanks, Ahmed On Thu, Jan 16, 2020 at 10:29 AM Fernando J. Iglesias García < fernando.igles...@shogun-toolbox.org> wrote: > Hi Ahmed, > > Great to hear from you! Apologies for the long delayed reply, the e-mail > was directly archived and I didn't notice it until now. > > I like the idea. > > How would you like to proceed? > We are currently in GSoC 2020 application period and we will apply as > mentoring org. Would you like to participate with Shogun in 2020 as student > or even mentor? > We could make your generic testing with introspection idea a project > proposal, or part of one. > > Cheers, > Fernando. > > On Tue, 10 Dec 2019 at 18:44, Ahmed Essam via shogun-list < > shogun-list@shogun-toolbox.org> wrote: > >> Hello all, >> >> Currently, there is no systematic testing of classes that does not >> require the manual enumeration of new sub-classes. An attempt to make a >> testing framework that can automatically test class families has been made >> in PR #4712 <https://github.com/shogun-toolbox/shogun/pull/4712>. >> >> I want to make progress towards a systematic framework for class testing >> with the following goals: >> 1. Provide a reflection-like metaprogramming method to enumerate the >> class hierarchy. >> 2. Use this generated information to create static typed tests. This >> differs from the previous PR in that: (a) we don't need to update class >> lists manually, and (b) provide a neat way to specialize tests given the >> used type. >> >> We can do this by extending the "class_list.py" script to generate the >> whole class hierarchy, and using a template language to answer type queries. >> Here is an example of what that would look like: >> IterativeMachine_unittest.cc >> <https://gist.github.com/theartful/5413ad7cf0889e4fd87f518a5b6ed869>. >> >> I have a working example locally that uses the exact same syntax. There >> is a shortcoming of this approach: the parsing is done by an ad-hoc python >> script. A possible solution is to use a tool to automate the parsing like >> jinja, which has been used before in 'clone_unittest.cc`. >> >> Since there are multiple ad-hoc python scripts that parse specific files, >> I think we can extend this proposal to other parts of the code base to >> unify template file generation. >> >> Thanks, >> Ahmed Essam. >> >
