Page Comparison

1. To resolve this try to first run python -tt <ptl_test_file> to verify that no syntax error were made
2. If 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
   
   1. pbs_benchpress -f pbs_cgroups_tests.py -t TestCgroups

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

1. I recommend placing them under pbspro/test/tests

1. Follow instructions from this page

1. pbs_benchpress -f <my_tests.py>

1. For example if I had a test suite called TestCgroups in file pbs_cgroups_tests.py I would execute the following
   
   1. pbs_benchpress -f pbs_cgroups_tests.py -t TestCgroups
2. If I wanted to run two specific tests in the TestCgroups I would do
   1. pbs_benchpress -f pbs_cgroups_tests.py -t TestCgroups.test_t4b,TestCgroups.test_t4c

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

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

2. If custom tearDown() defined then it should do reverting test case specific operations example "changing system configuration" then call parent class tearDown().

3. If PTL revert function don’t revert some of PBS settings then should that be treated as PTL bug/enhancements

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

1. Your Github Pull Request should only have 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 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.