Add pytest testing

[reynoldsnlp]

Suggestion from @ncoghlan here

Graceful handling of edge cases is going to be an ongoing theme with this utility, so the next step would be to starting adding pytest test cases, using a layout similar to the existing one in pip (https://github.com/pypa/pip/tree/master/tests/):

Grab a couple of simple test packages from https://github.com/pypa/pip/tree/master/tests/data/packages (you won't need the whole set, since you're only testing pip_inside's ability to call pip correctly, not pip's ability to install a wide variety of packages). https://github.com/pypa/pip/blob/master/tests/data/packages/simplewheel-1.0-py2.py3-none-any.whl and v2.0 of the same package would probably be good ones to use Create tests/functional/test_install_via_api_wrapper.py to hold the test cases that could later be dropped directly into pip's own test suite (if/when the API gets added back to the main project) Some possible example test cases to start with given the potential problems I noted above:

install("pip install --target /tmp//target_dir_without_spaces ''") install("pip install --target '/tmp//target dir with spaces' ''") install("", target="/tmp//") followed by install("", target="/tmp//", upgrade=True) In the long run, you'd change the test cases to mock out subprocess.run and just check that the arguments passed in are the ones you expect to be receiving (since that will run much much faster than actually doing the installs, and will let you get rid of the data files from the test suite).

Initially, though, you want to build confidence that the test cases are actually testing what you want them to test, so it's better to actually run pip for real with a specified target directory.

[reynoldsnlp]

Rather than mock up subprocess.run, I just divided the install function into two functions: one to build the command, and the other to run it. That way pytest can just test whether the command-building function is doing the right thing.