Repository navigation
"Test result not found" if cwd is a subdirectory in the workspace #18030
Description
VS Code version
1.62.2
Extension version
v2021.11.1422169775
OS type
macOS
OS version
10.15.7
Python distribution
python.org
Python version
Python 3.9.5
Language server
None or Disabled
Expected behaviour
Test results should show after running tests using Testing sidebar.
Actual behaviour
Exception raised after test finished running:
Test result not found for: ./tests/test_mod.py::test_1
Steps to reproduce
Structure of the repository that reproduces the issue:
.
├── .gitignore
├── README.md
├── backend
│ ├── .python-version
│ ├── Pipfile
│ ├── Pipfile.lock
│ ├── src
│ │ └── testmod
│ │ └── __init__.py
│ └── tests
│ ├── conftest.py
│ └── test_mod.py
└── test-pytest.code-workspace
I included in the repository the settings.json used. That shows:
{
"python.defaultInterpreterPath": "/Users/adri0/.local/share/virtualenvs/backend-kdNxFSnI",
"python.terminal.activateEnvironment": true,
"python.terminal.activateEnvInCurrentTerminal": true,
"python.testing.cwd": "${workspaceFolder}/backend",
"python.testing.pytestEnabled": true,
"python.testing.unittestEnabled": false,
"python.testing.pytestArgs": [
"tests/"
]
}
I noticed that if I change the cwd to ${workspaceFolder} and move the tests folder to the repository root, it works.
Logs
cwd: ~/code/test-pytest-clone/backend
> ~/.local/share/virtualenvs/backend-kdNxFSnI/bin/python ~/.vscode/extensions/ms-python.python-2021.11.1422169775/pythonFiles/testing_tools/run_adapter.py discover pytest -- --rootdir ~/code/test-pytest-clone/backend -s --cache-clear tests/
Code of Conduct
- I agree to follow this project's Code of Conduct
Activity
karthiknadig commentedon Nov 15, 2021
Adriano Oliveira (@adri0) Here are the changes I made to get this working see if it works for you:
This is the structure:
The "tests" are out side of the
srcfolder.Remove the
settings.json, as you can see I don't have a.vscodefolder.This is my
workspace.code-workspace:I did some minor tweaks to the
cwdandpytestAtgssettings.It seems to be working:
karthiknadig commentedon Nov 15, 2021
Let me know if the above changes work for you.
adri0 commentedon Nov 16, 2021
The problem does go away when I change the folder structure for the one proposed. The issue with it is that in some real life projects it's not an option for me to have the tests folder directly under the root directory, as the Python code is a component of a bigger project.
Thus I thought, why not change the
python.testing.cwdconfig to match the folder structure, given I'm allowed to change it. When I notice this prevents the tests to work properly I thought this behaviour could be a bug.adri0 commentedon Nov 16, 2021
Thanks about the
settingsin the workspace file tip. It does simplify things. I'll update the sample project.adri0 commentedon Nov 16, 2021
I made an edit in the first comment. The actual folder structure should be
./backend/testsinstead of./tests.stilren commentedon Nov 24, 2021
I am also seeing issues with this. We have a very nested directory structure since we are deploying aws lambdas and each lambda has its own test folder
setting
"python.testing.cwd": "${workspaceFolder}/app"
throws the same type of error.
Here is a minimal example showing this error:
Folder structure
contents of test_example.py
contents of settings.json
tinix0 commentedon Nov 25, 2021
I can also confirm the same. We have tests in a subdirectory of the workspace with code directly in root.
Settings:
"python.testing.cwd": "${workspaceFolder}/unit_tests"
changeling commentedon Feb 16, 2022
I'm having this same (or similar) issue, though my tests are not in a subdirectory.
Clicking on
Run Testsin the test panel yieldsTest result not found for: ./tests/[test_name].py::test_no_argument.Here's the twist, though: Clicking on
Rerun Failed Testsafter the fail yields a complete, successful run.Subsequent to that, clicking on
Run Testsfails again. So I can successfully run my tests, but only by clicking onRerun Failed Testsafter first attempting to run.In addition, running the individual tests by clicking on their respective
Run Testbuttons works fine.My directory looks like this:
│── .gitignore
│── README.md
│── src
│ └── example.py
│── tests
│ └── test_example.py
VS Code version
Version: 1.64.2
Python extension version
v2022.0.1814523869
OS: Darwin x64 19.6.0 (macOS 10.15.7)
eleanorjboyd commentedon Oct 4, 2023
Hello! We have just finished our testing rewrite and are beginning the roll out to users. If you are able, it would be very helpful to know if your issue still exists on the rewrite! To try it yourself, add this setting to your users
settings.json"python.experiments.optInto": ["pythonTestAdapter"].You can confirm you have the rewrite enabled by setting
"python.analysis.logLevel": "Trace",in your user settings then check forExperiment 'pythonTestAdapter'is active in your python logs.Let me know if the rewrite fixes your issue. Thanks!
eleanorjboyd commentedon Oct 30, 2023
closing as there has been no activity on this issue in a month, please comment to reopen. Thanks
Rafq77 commentedon Nov 7, 2023
Hi, it seems to work just fine, however I have some problems with tests that use MagicMock as file descriptor instance.
I could test the fixes by enabling in my user
settings.jsonthe"python.experiments.optInto": ["pythonTestAdapter"]successfully. However,"python.analysis.logLevel"is an "Unknown Configuration Setting" for my vscode instance.My test setup is following:
VS Code version
1.84.0
Extension version
v2023.21.13101009
OS type & version
Windows 10
Python version
Python 3.11.2
Given following test:
The process crashes internally.
Note: ⚠ That, if this test is run in debug mode 🐞 with/-out breakpoints, it completes flawlessly ✅.
Due to the not working
analysis.logLevelsetting on my side, I don't have elaborate logs, except for those pluggy(?) errors:ajoga commentedon Nov 13, 2023
Hi Eleanor Boyd (@eleanorjboyd) -- this, followed by a window reload just fixed the issue that seems more or less the same as the author or this ticket. Thank you!
eleanorjboyd commentedon Nov 27, 2023
Hello Rafal S (@Rafq77), sorry for the delay as I was on vacation.
Could you open up a separate issue for the bug you are seeing? It is very interesting but seems less related to the current thread and a new thread would allow me to analyze it further. Thanks!