While the approach described in https://pytest-subprocess.readthedocs.io/en/latest/usage.html#check-popen-arguments to check Popen args works, it has the disadvantage of splitting the details on how a call is expected to be invoked between the fp.register call and the subsequent check of the recorded call details. This means it can be tricky to associate the invalid call with the code responsible for making it.
If this check is instead performed in the callback function, the traceback for the failing test case assertion directly identifies the incorrectly configured subprocess call (similar to what happens for attempts to invoke unregistered commands).
This is a docs enhancement suggestion rather than a feature requests, as it's already possible to check Popen args directly in a callback function by using the kwargs property on the FakePopen instance using code like:
def fp_callback(process):
assert process.kwargs.env["EXPECTED_ENV_VAR"] == EXPECTED_VALUE
(My specific use case is checking for settings that are expected to be passed to the subprocess as environment variables rather than as command line options, hence the choice of example)
Happy to write a PR if this seems like a reasonable addition.
While the approach described in https://pytest-subprocess.readthedocs.io/en/latest/usage.html#check-popen-arguments to check
Popenargs works, it has the disadvantage of splitting the details on how a call is expected to be invoked between thefp.registercall and the subsequent check of the recorded call details. This means it can be tricky to associate the invalid call with the code responsible for making it.If this check is instead performed in the callback function, the traceback for the failing test case assertion directly identifies the incorrectly configured subprocess call (similar to what happens for attempts to invoke unregistered commands).
This is a docs enhancement suggestion rather than a feature requests, as it's already possible to check
Popenargs directly in a callback function by using thekwargsproperty on theFakePopeninstance using code like:(My specific use case is checking for settings that are expected to be passed to the subprocess as environment variables rather than as command line options, hence the choice of example)
Happy to write a PR if this seems like a reasonable addition.