It does not really make sense to produce this feature, since it only generates (unnecessary and now deprecated dependencies). We should disable this by default and rethink that approach.
E.g. it probably should collect all fragments that end with ".test(s|ing)" in a separate Metadata object and then list them in the template.
Also I am not sure if it makes sense to generate test fragments for the generated nodes/plugin. They all follow the same schema, so the basic functionality should probably be tested in the GKN nodegeneration plugin (which we still need to separate). Best would probably be:
1) Separate nodegenerator
2) For every change in nodegenerator, create a test plugin (see the already present examples)
3) (b is probably easier and enough)
a) Build (with e.g. buckminster) a nodegenerator test plugin+feature with a preconfigured set of tests (not auto-generated together with the test plugin; would still have to be written)
b) Download a premade Testworkflow that includes the node to be generated
4) Use p2director to headless install KNIME product + testing.application + GKN (nightly UpdS) (+ locally built nodegenerator test feature)
5) Run the tests on the nodes (NGUnittest/NGTestflow application from knime.testing.application)
BUT: This is kind of already tested with the OpenMS plugin generation so for now this is not high priority.
Since the Testing feature template is always empty: https://github.com/genericworkflownodes/GenericKnimeNodes/blob/develop/com.genericworkflownodes.knime.node_generator/src/com/genericworkflownodes/knime/nodegeneration/templates/testingfeature/testingfeature.xml.template#L22
It does not really make sense to produce this feature, since it only generates (unnecessary and now deprecated dependencies). We should disable this by default and rethink that approach.
E.g. it probably should collect all fragments that end with ".test(s|ing)" in a separate Metadata object and then list them in the template.
Also I am not sure if it makes sense to generate test fragments for the generated nodes/plugin. They all follow the same schema, so the basic functionality should probably be tested in the GKN nodegeneration plugin (which we still need to separate). Best would probably be: 1) Separate nodegenerator 2) For every change in nodegenerator, create a test plugin (see the already present examples) 3) (b is probably easier and enough) a) Build (with e.g. buckminster) a nodegenerator test plugin+feature with a preconfigured set of tests (not auto-generated together with the test plugin; would still have to be written) b) Download a premade Testworkflow that includes the node to be generated 4) Use p2director to headless install KNIME product + testing.application + GKN (nightly UpdS) (+ locally built nodegenerator test feature) 5) Run the tests on the nodes (NGUnittest/NGTestflow application from knime.testing.application)
BUT: This is kind of already tested with the OpenMS plugin generation so for now this is not high priority.