Test setup and teardown with Python TestHarness

[bielsnohr]

From my inspection of the documentation about the Python TestHarness and the source itself, it doesn't appear there is an easy way to do any sort of test setup or teardown. In the particular case for the MOOSE app I have developed, I need to copy a file to a specific location before the test and then remove it after the test.

Any ideas how I might go about this?

I suspect writing my own Tester might be the answer, but then how to link that into the existing TestHarness framework?

[milljm]

You can create several tests which all depend on one another, each doing a special job:

[Tests]
  [./testA]
    type = RunCommand
    command = "cp ../foo.i ."
  [../]
  [./testB]
    type = RunApp
    input = foo.i
    prereq = testA
  [../]
  [./testC]
    type = RunCommand
    command = "cp foo.e ../"
    prereq = testB
  [../]
[]

There are a lot of examples available in moose/test/tests/test_harness which we use as controls/unittests.

[permcody]

While this would indeed work, I'm not a huge fan of "abusing" the system like this. You can certainly add a custom Tester to the system. If you have your own app, it's just a matter of dropping it into the right directory in your App and our system will automatically pick it up, register it, and let you use it. While setup and tear down is a normal operation, we don't have a lot of need for that in our integration test suite. Note that if you use Gtest for "component" level testing, you can create those methods like you'd expect.

What are you trying to do? Can you just soft link those files into the right locations so you don't have to setup and tear down? Maybe we can come up with other ways of solving your problem.

[milljm]

Specifically this directory:

<app_dir>/scripts/TestHarness/testers

[bielsnohr]

Thank you for answering this, and apologies for not coming back to reply. I did go with @milljm 's first suggestion in the end, and it worked for me.

However, I do agree this is a bit of an 'abuse' of the system that should be moved to the more robust solution of writing a bespoke Tester as suggested by @permcody . My use case was a slightly abnormal one: the input file for an externally run program (called from an ExternalProblem class) also functioned as the output file for that external program. So, a simple symlink won't work because the input file will have changed by the end of the test run, making it unsuitable for future use. This is why I needed the proper clone copy.