Change Details

Moving regression tests to python has shown that there's an awful lot of duplicated code that could be simplified. The general approach here should be to move code into the `pacemaker._cts` python module. Here's some ideas - feel free to break these out into individual tasks. * Several tools have an `update_path` function that sets various environment variables. * valgrind options are specified in multiple places. * Most (all?) regression tests have some sort of XyzTest and XyzTests classes, with an awful lot of duplication. These classes typically always have some sort of setup and teardown methods, a run method, and a results reporting method. These could also overlap with the Test class in `pacemaker._cts.test`. * Most (all?) regression tests have a function for reading command line options. I doubt we are at all consistent with what options are supported by what tests. * There's a lot of general library code sprinkled around that, even if it's not duplicate stuff, should probably move into the `pacemaker._cts.test`. Examples of this are functions to pluralize strings, diffing files, checking if something is executable, etc. * There's likely a lot of duplication in how we run an external process. Anywhere that subprocess is being used is a candidate for simplification. There's already a `pacemaker._cts.process` module to condense this into.

Moving regression tests to python has shown that there's an awful lot of duplicated code that could be simplified. The general approach here should be to move code into the `pacemaker._cts` python module. Here's some ideas - feel free to break these out into individual tasks. * Several tools have an `update_path` function that sets various environment variables. * valgrind options are specified in multiple places. * Most (all?) regression tests have some sort of XyzTest and XyzTests classes, with an awful lot of duplication. These classes typically always have some sort of setup and teardown methods, a run method, and a results reporting method. These could also overlap with the Test class in `pacemaker._cts.test`. * Most (all?) regression tests have a function for reading command line options. I doubt we are at all consistent with what options are supported by what tests. * There's multiple places that diff files. Investigate using difflib (https://docs.python.org/3.6/library/difflib.html) for this. * There's a lot of general library code sprinkled around that, even if it's not duplicate stuff, should probably move into the `pacemaker._cts.test`. Examples of this are functions to pluralize strings, checking if something is executable, etc. * There's likely a lot of duplication in how we run an external process. Anywhere that subprocess is being used is a candidate for simplification. There's already a `pacemaker._cts.process` module to condense this into.

Moving regression tests to python has shown that there's an awful lot of duplicated code that could be simplified. The general approach here should be to move code into the `pacemaker._cts` python module. Here's some ideas - feel free to break these out into individual tasks. * Several tools have an `update_path` function that sets various environment variables. * valgrind options are specified in multiple places. * Most (all?) regression tests have some sort of XyzTest and XyzTests classes, with an awful lot of duplication. These classes typically always have some sort of setup and teardown methods, a run method, and a results reporting method. These could also overlap with the Test class in `pacemaker._cts.test`. * Most (all?) regression tests have a function for reading command line options. I doubt we are at all consistent with what options are supported by what tests. * There's multiple places that diff files. Investigate using difflib (https://docs.python.org/3.6/library/difflib.html) for this. * There's a lot of general library code sprinkled around that, even if it's not duplicate stuff, should probably move into the `pacemaker._cts.test`. Examples of this are functions to pluralize strings, diffing files, checking if something is executable, etc. * There's likely a lot of duplication in how we run an external process. Anywhere that subprocess is being used is a candidate for simplification. There's already a `pacemaker._cts.process` module to condense this into.