namespace test
{
-/*! \libinternal \brief Declares test fixture for integration tests of
- * mdrun functionality
+/*! \libinternal \brief Helper object for running grompp and mdrun in
+ * integration tests of mdrun functionality
*
- * Derived fixture classes (or individual test cases) that might have
- * specific requirements should assert that behaviour, rather than
- * hard-code the requirements. A test that (for example) can't run
- * with more than one thread should report that as a diagnostic, so the
- * person running the test (or designing the test harness) can get
- * feedback on what tests need what conditions without having to read
- * the code of lots of tests.
+ * Objects of this class are intended to be owned by
+ * IntegrationTestFixture objects, and an IntegrationTestFixture
+ * object might own more than one SimulationRunner.
*
* The setup phase creates various temporary files for input and
* output that are common for mdrun tests, using the file manager
- * object of the parent class. Individual tests should create any
- * extra filenames similarly, so that the test users's current working
- * directory does not get littered with files left over from all
- * manner of tests.
- *
- * Specifying the execution context (such as numbers of threads and
- * processors) is normally sensible to specify from the test harness
- * (i.e. when CMake/CTest/the user runs a test executable), because
- * only there is information about the hardware available. The default
- * values for such context provided in test fixtures for mdrun should
- * mirror the defaults for mdrun, but currently mdrun.c hard-codes
- * those in a gmx_hw_opt_t.
+ * object of the fixture that owns this object. Individual tests
+ * should create any extra filenames similarly, so that the test
+ * users's current working directory does not get littered with files
+ * left over from tests.
*
* Any method in this class may throw std::bad_alloc if out of memory.
*
* \ingroup module_mdrun_integration_tests
*/
-class MdrunTestFixture : public IntegrationTestFixture
+class SimulationRunner
{
- protected:
- MdrunTestFixture();
- virtual ~MdrunTestFixture();
+ public:
+ /*! \brief Constructor, which establishes the fixture that
+ * will own each object */
+ explicit SimulationRunner(IntegrationTestFixture *fixture_);
//! Use an empty .mdp file as input to grompp
void useEmptyMdpFile();
* with default command line */
int callMdrun();
+ private:
+ //! Provides access to the test fixture, e.g. for the TestFileManager
+ IntegrationTestFixture *fixture_;
+ public:
//@{
/*! \name Names for frequently used grompp and mdrun output files
*
* in a temporary directory and (by default behaviour of
* TestFileManager) deleted when the test is complete.
*/
- std::string topFileName;
- std::string groFileName;
- std::string fullPrecisionTrajectoryFileName;
- std::string reducedPrecisionTrajectoryFileName;
- std::string groOutputFileName;
- std::string ndxFileName;
- std::string mdpInputFileName;
- std::string mdpOutputFileName;
- std::string tprFileName;
- std::string logFileName;
- std::string edrFileName;
- std::string cptFileName;
- std::string swapFileName;
- int nsteps;
+ std::string topFileName_;
+ std::string groFileName_;
+ std::string fullPrecisionTrajectoryFileName_;
+ std::string reducedPrecisionTrajectoryFileName_;
+ std::string groOutputFileName_;
+ std::string ndxFileName_;
+ std::string mdpInputFileName_;
+ std::string mdpOutputFileName_;
+ std::string tprFileName_;
+ std::string logFileName_;
+ std::string edrFileName_;
+ std::string cptFileName_;
+ std::string swapFileName_;
+ int nsteps_;
//@}
};
+/*! \libinternal \brief Declares test fixture base class for
+ * integration tests of mdrun functionality
+ *
+ * Derived fixture classes (or individual test cases) that might have
+ * specific requirements should assert that behaviour, rather than
+ * hard-code the requirements. A test that (for example) can't run
+ * with more than one thread should report that as a diagnostic, so the
+ * person running the test (or designing the test harness) can get
+ * feedback on what tests need what conditions without having to read
+ * the code of lots of tests.
+ *
+ * Specifying the execution context (such as numbers of threads and
+ * processors) is normally sensible to specify from the test harness
+ * (i.e. when CMake/CTest/the user runs a test executable), because
+ * only there is information about the hardware available. The default
+ * values for such context provided in test fixtures for mdrun should
+ * mirror the defaults for mdrun, but currently mdrun.c hard-codes
+ * those in a gmx_hw_opt_t.
+ *
+ * Any method in this class may throw std::bad_alloc if out of memory.
+ *
+ * \ingroup module_mdrun_integration_tests
+ */
+class MdrunTestFixtureBase : public IntegrationTestFixture
+{
+ public:
+ MdrunTestFixtureBase();
+ virtual ~MdrunTestFixtureBase();
+};
+
+/*! \libinternal \brief Declares test fixture class for integration
+ * tests of mdrun functionality that use a single call of mdrun
+ *
+ * Any method in this class may throw std::bad_alloc if out of memory.
+ *
+ * \ingroup module_mdrun_integration_tests
+ */
+class MdrunTestFixture : public IntegrationTestFixture
+{
+ public:
+ MdrunTestFixture();
+ virtual ~MdrunTestFixture();
+
+ //! Helper object to manage the preparation for and call of mdrun
+ SimulationRunner runner_;
+};
+
/*! \libinternal \brief
* Parameterized test fixture for mdrun integration tests
*/
biod.pnpi.spb.ru / alexxy / gromacs.git / blobdiff