FAQs

1. When I run "pbs_benchpress -t TestCgroups", I get "unknown testsuite: TestCgroups" error, even though "TestCgroups" is a valid test suite name. How do I resolve this?

   1. To resolve this First, try to first run python -tt <ptl_test_file> to verify that no syntax error errors were made
   2. If the test file has executable permission then , remove it (recommended permission for test file is 0644)
   3. If that doesn't work, provide the path to the ptl_test_file using the -f
      option, e.g. pbs_benchpress -f pbs_cgroups_tests.py -t TestCgroups

2. Should I run the PTL test suite on my production environment?

   1. Never run ptl PTL test cases in the production environment. It will only take once before for you to regret it. PTL is designed to will delete all of the job jobs and restore the system to the default config that it needs to run the testsconfiguration!

3. Where should I place the new tests?

   1. I recommend placing Put them under pbspro/test/tests.  See our test directory structure.

4. What should I name the tests?

   1. Follow instructions from this pageour PTL naming conventions!

5. How can I

   find the

   specify a file

   when

   that pbs_benchpress

   cant

   can't find

   it

   ?

   1. pbs_benchpress -f <my<name of test file>  For example, pbs_benchpress -f my_tests.py>py

6. How can I run only a specific test?

   1. Specify the test using the -t option.  For example, if

      I had

      you have a test suite called TestCgroups in a file named pbs_cgroups_tests.py

      I would

      , execute the following:

      1. pbs_

         benchpress

         bench press -f pbs_cgroups_tests.py -t TestCgroups

   2. If I wanted to

      To run two specific tests in the TestCgroups

      I would do

      suite:

      1. pbs_benchpress -f pbs_cgroups_tests.py -t TestCgroups.test_t4b,TestCgroups.test_t4c

7. Is custom tearDown() necessary? if we define custom tearDown() explicitly in the test, do we need to call parent class teardown()?

   1. If the test case is doing some operations which PTL does not revert, for example "changing system configuration" then , the test case should define custom tearDown().

   2. If custom tearDown() is defined then in the test, it should do reverting perform test-case-specific reverting operations.  For example if it does "changing system configuration" then , it should call parent class tearDown().

   3. If the PTL revert function don’t doesn’t revert some of PBS settings then , it should that be treated as a PTL bug/enhancementsenhancement.

8. How can I run all tests under the 'functional' directory?

   1. Try the "--follow-child" option to pbs_benchpress:
      1. pbs_benchpress -t TestFunctional --follow-child

9. Can I submit a PTL test which fails now, but will pass when condition x is met? (e.g

   :

   ., when a known bug is fixed, or a known PTL enhancement is implemented)

   1. Your Github Pull Request should only have GitHub pull request should use only those new/modified PTL tests which pass, as evidenced by test logs. If there's a test case that is important, but has a dependency on some other code change, you have a few options:
      1. if If your code change is not time-critical, then the best approach is to just hold off until the dependency is resolved.
      2. If your code change is time-critical and you have an entire test case/test suite which will fail, then you could use PTL's skip functionality to skip it and explain the dependency, then add a new ticket which should be linked to the dependency so that it can be tracked.
      3. If there's only a small section of a test case which would cause failure, and it's an important check, then you could again create a ticket, put that section there, and link it to the dependency so that it can be added once it's resolved.