Another way to look at it is that, aside from the do_run method and one use of os.path.exists, cmdline.py is functionally pure. It takes the command-line arguments and builds a work plan or outputs useful diagnostics/docmentation.

The test is painful to add because os.path.exists exercises a side effect to pull in the enormous super-global variable that is system state. It’s painful and out-of-place in the existing tests because the rest don’t need it. This object isn’t about producing side effects, it’s about parsing user input.

Imagine if the data of what work to do were separated from the side-effectful methods that read system state and kick off test jobs. You’d have your existing tests of all the command-line arg parsing that’s going to call methods with different args and assert on their return values, and for the new code you’d have a new test file that’s going to pass those data objects in, mock the outside world, and assert that those mocks were called correctly (maybe with a few assertions on return values).