Use same pytest --rootdir logic as test discovery

[bhrutledge]

This is a quick submission via github.dev, so please pardon the lack of local testing and adherence to the contributing guidelines.

For #9553, specifically re: the second issue described in #9553 (comment).

FYI @karthiknadig, who touched this code in #17509.

[bhrutledge]

Based on the logic below, this should use python.testing.cwd if it's set, otherwise the --rootdir option from python.testing.pytestArgs.

vscode-python/src/client/testing/testController/pytest/pytestController.ts

Lines 288 to 299 in b6c0d3e

	return this.runner.runTests(
	testRun,
	{
	workspaceFolder: workspace.uri,
	cwd:
	settings.testing.cwd && settings.testing.cwd.length > 0
	? settings.testing.cwd
	: workspace.uri.fsPath,
	token,
	args: settings.testing.pytestArgs,
	},
	this.idToRawData,

[karthiknadig]

@bhrutledge Can you provide a news file under news/2 Fixes with name 9553.md with content something like (so you get credit for this fix):

Partial fix for using the same directory as discovery while running.
(thanks [Brian Rutledge](https://github.com/bhrutledge))

[ghost]

All CLA requirements met.

[karthiknadig]

@bhrutledge Please sign the CLA so we can review and merge this.

[bhrutledge]

Please sign the CLA so we can review and merge this.

@karthiknadig Sorry for the delay on this; I haven't signed a CLA before, and was waiting on some advice.

In the meantime, I've installed the VSIX locally and verified that it sets --rootdir appropriately in my example repo. IE, given "python.testing.cwd": "repo/rootdir", running a single test file yields:

> ~/Dev/vscode-pytest-workspace/venv/bin/python -m pytest --rootdir ~/Dev/vscode-pytest-workspace/repo/rootdir --override-ini junit_family=xunit1 --junit-xml=/var/folders/bw/ttgk1hcs0k989q2yzmxkzn8c0000gp/T/tmp-12273mm0YANFsJ0JF.xml ./package/test_module.py

Aside: I didn't find any documentation on how to use a VS Code extension while it's being developed, without manually installing the VSIX. I'm thinking of something equivalent to the "editable installs" provided via pip and setuptools. Is that possible? Can somebody point me in the right direction?

Speaking of testing: I note that a check failed because this PR doesn't include TypeScript tests. However, it's not clear to me where to write such a test, and I note that #17509 didn't include tests. Any suggestions?

[bhrutledge]

@karthiknadig ICYMI, I've signed the CLA.

[karthiknadig]

@bhrutledge here are some instructions on how to build and run the extension during development.

Build environments and compiling: https://github.com/microsoft/vscode-python/wiki/Coding
Running the code under debugger: https://github.com/microsoft/vscode-python/wiki/Testing#debugging

There aren't any tests for this. I added this code as an intermediate step till we get to point of updating the pytest adapter. I think the test adapter that we currently use tries to do things that it should probably let pytest handle itself. We are currently in the process of re-doing the test adapters starting with the unittest adapter first, and pytest will be next. So most of this code will go away when we get to that point.

[bhrutledge]

here are some instructions on how to build and run the extension during development.

Thanks @karthiknadig. I had read over those, but they didn't answer my question; I've opened #17931 for assistance.

We are currently in the process of re-doing the test adapters

I'm interested in following this. Can you share some relevant links?

For this PR, is there anything else you need from me?

[bhrutledge]

@karthiknadig Can you take another look at this? Looks like some checks are still pending; don't know why.

[bhrutledge]

This failing test doesn't seem related to this change: https://github.com/microsoft/vscode-python/runs/4143672875?check_suite_focus=true

[karthiknadig]

That is due to pipenv ending support for 2.7.