Closed mathiaswagner closed 9 years ago
I don't think the length of --help
is a big deal since this the internal tests are really only going to be used by the QUDA developers.
I agree.
The motivation behind the test options was the option for xml output which can be interpreted e.g. by Jenkins. All this aims towards getting our test suite ready for more automated testing.
Right now I would like this to go in a direction where we do have tests as we have them today (from a user perspective, i.e. similar usage) but also do have tests that will be rely on the google test framework and run several tests from within one binary, like e.g. running the dslash for different precisions, sizes, partitions.
I have been refreshing my google test knowledge a bit and looked at the structure of the internal tests but this is still more in the concept phase and I have not written any code for that.
Of course all these things do not help with multiple build options and multi-node / multi-gpu options / layout etc, but may be a first step.
closed with #258
The google test framework provides some options to control test execution and output. This might be useful when we go for automated testing. As a first step we should add
::testing::InitGoogleTest()
to themain
routines of the tests.I have started the branch _feature/gtestoptions and added this to the _staggered_slashtest. The output of help is now quite long - if that is annoying we can add a flag to make.inc.in.
For the long run we might think about something like test_classes so that we can run different test from one executable and defining them as different google_tests. By moving this to a function or class we could also keep the current tests (strip the real test and just keep the infrastructure for running).
We could than have a dslash_gtest that tests the Dslash e.g. with the different precisions (each as a different test).
But maybe as a first step adding the gtest options is a good thing ?
Thoughts?