search

EnzymeFunctionInitiative / EST

Programs for creating Sequence Similarity Networks and wrappers for pipeline submission on a torque cluster
GNU General Public License v3.0
6 stars 4 forks source link

Support multiple test configurations #77

Open nilsoberg opened 2 months ago

nilsoberg commented 2 months ago

Allow different test configurations to be run. The motivation is to support testing multiple import modes. For example:

bash tests/runtests.sh docker.config basic would run the most basic import tests

bash tests/runtests.sh docker.config uniref90 would run the import tests using UniRef90 sequences

bash tests/runtests.sh docker.config uniref90_no_frac would run the import tests using UniRef90 sequences plus the no-fraction import option

It is proposed to have directories under tests/modules that represent the new test case parameter (e.g. basic, uniref90, uniref90_no_frac).

nilsoberg commented 2 months ago

This could be solved by #65, but this issue solves a much simpler problem and is a stop-gap solution for more comprehensive testing.

nilsoberg commented 1 month ago

I suggest closing this issue because #85 has solved part of this problem. All tests should be specified in the modules directory, and if they are not to be run they can temporarily be moved to the modules/disabled directory (i.e. if only a specific test needs to be run). This is a basic approach to testing but it works for now. @1ndy

1ndy commented 1 month ago

In an automated testing scenario, moving files in and out of directories would add complexity. Being able to disable tests with flags or a config file would make it easier to run in a CI/CD pipeline. I know that isn't a goal right now so this is fine to use but maybe some thorough documentation of that strategy can be added in this issue?

nilsoberg commented 1 month ago

In an automated testing scenario, moving files in and out of directories would add complexity. Being able to disable tests with flags or a config file would make it easier to run in a CI/CD pipeline. I know that isn't a goal right now so this is fine to use but maybe some thorough documentation of that strategy can be added in this issue?

You mean document the proposed approach in the issue or something for the future?

1ndy commented 1 month ago

Use this issue to create a branch in which you update the documentation to describe how tests can be disabled.