Running test fails trying to access non-existing file

[tenspd137]

Using vscode-python 2020.6.88468
VSCode 1.46.0

When I run a test using the pytest framework, there is always an error at the end of the log:

Error: Error: cannot open file:///c%3A/Code/pixelcrunch/C. Detail: Unable to read file 'c:\Code\pixelcrunch\C' (Error: Unable to resolve non-existing file 'c:\Code\pixelcrunch\C')

regardless if the test itself actually passes or fails:

I don't know what is causing it to look for this file.

[tenspd137]

Also, when I try to set a breakpoint and debug the test, I get the following:

============================= test session starts =============================
platform win32 -- Python 3.8.3, pytest-5.4.3, py-1.8.2, pluggy-0.13.1
rootdir: c:\Code\pixelcrunch
collected 0 items / 1 error

=================================== ERRORS ====================================
____________ ERROR collecting pixelcrunch/tests/test_crunchers.py _____________
ImportError while importing test module 'C:\Code\pixelcrunch\pixelcrunch\tests\test_crunchers.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
pixelcrunch_init_.py:13: in
import pandas as pd
C:\Miniconda3\envs\pychar2\lib\site-packages\pandas_init_.py:16: in
raise ImportError(
E ImportError: Unable to import required dependencies:
E numpy:
E
E IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!
E
E Importing the numpy C-extensions failed. This error can happen for
E many reasons, often due to issues with your setup or how NumPy was
E installed.
E
E We have compiled some common reasons and troubleshooting tips at:
E
E https://numpy.org/devdocs/user/troubleshooting-importerror.html
E
E Please note and check the following:
E
E * The Python version is: Python3.8 from "C:\Miniconda3\envs\pychar2\python.exe"
E * The NumPy version is: "1.18.5"
E
E and make sure that they are the versions you expect.
E Please carefully study the documentation linked above for further help.
E
E Original error was: DLL load failed while importing _multiarray_umath: The specified module could not be found.

I don't know what causes this. Importing pandas at the command line has no problems:

This happens on tests that pass or fail, regardless.

[tenspd137]

I cant downgrade right now wither, because I currently am affected by issue #99699 -
microsoft/vscode#99699

[tenspd137]

New information - works with python 3.6, not with 3.7 or 3.8

[tenspd137]

Works with python 3.8 if I run conda activate , cd to project folder, and start vscode using "code ." I wonder if it is ignoring some environment setup somehow? This is a workable solution for me, but not ideal. I'll leave it open since it isn't working as expected.

[int19h]

Which log do you see that error message (about file://) in?

The second issue might have something to do with conda environment not getting activated properly. Try activating it manually in an external terminal, and then launching VSCode from said terminal. If that doesn't help, can you please file a separate issue in https://github.com/microsoft/vscode-python/.

[tenspd137]

It shows up in the python test log. It happens after a test fails, and then doesn't seem to go away, even on tests that pass. If I start vscode and run a test that passes, I don't see it, until a test fails. Then it happens after every test.

[tenspd137]

Starting vscode from the directory after starting the environment fixes first problem. Still see file:// problem:

[tenspd137]

Re: Conda environment - I have several - if I select the 3.6 one, there is no problem. It is python 3.7 or 3.8 where the issue arises. Again, starting vscode from terminal works, just not ideal.

[int19h]

We're still trying to figure out automatic conda activation - it's a very complicated problem, unfortunately. You can track that work via #5344.

[int19h]

For the issue with file://, does this only happen when debugging the test, or regardless of how you run it?

[tenspd137]

It happens regardless on the first test that fails, and then the Error does not go away. Tests still report correctly as pass/fail in the panel, but it also shows:

So:
Vscode start
test that passes, no error
test that fails, error
test that passes, error
....

[int19h]

Looks like this is a test runner issue then - I'm going to move it back into the extension repo.

[tenspd137]

We're still trying to figure out automatic conda activation - it's a very complicated problem, unfortunately. You can track that work via #5344.

Understandable.....

[karrtikr]

@tenspd137 Unfortunately, I am not able to reproduce the issue you see after running the file.

Error: Error: cannot open file:///c%3A/Code/pixelcrunch/C. Detail: Unable to read file 'c:\Code\pixelcrunch\C' (Error: Unable to resolve non-existing file 'c:\Code\pixelcrunch\C')

Can you please paste your Python test log output panel after you run the file?

Also, please send a small reproducible example of the tests you're running, and also your settings.

[zooba]

I have a repro of this, and potentially some extra info (ping me internally if you want to more interactively debug)

I get this error message:

Error: Error: cannot open file:///c%3A/Projects/multiindex/X. Detail: Unable to read file 'c:\Projects\multiindex\X' (Error: Unable to resolve non-existing file 'c:\Projects\multiindex\X')

The interesting part here is my C:\Projects folder is actually a mount point to my X: drive. So here's my theory:

• something in the PyTest/test support is expecting a relative file path like tests\my_test_file.py
• PyTest resolved the path to the real drive
• the path is now absolute, and looks like X:\multiindex\tests\my_test_file.py
• PVSC is treating : as a separator (probably because it normally is on Unix?) and splitting the "X" off by itself
• it then combines the "relative" path X to the workspace root, which does not exist

Probably the best way to deal with this is to detect the absolute path, then fully resolve the workspace root ("realpath" equiv.) and recalculate the relative path. If it's still not within the workspace, then raise that as an error. Otherwise, you've found the file. Recalculating the relative path avoids opening the file in the editor twice, which is what will happen if you don't.

[karrtikr]

@zooba Great guess. It seems this line is the one throwing the error. Right above the line we're resolving file path similar to how you described.

Can you please paste your Python output panel & full Python test log output panel after you run the file?

Recalculating the relative path avoids opening the file in the editor twice, which is what will happen if you don't.

I am not sure how opening the file comes into the picture. So do you get this error when opening the file (navigating a suite/function/file etc.)? Note the original issue reports the error on just running the file - not opening it.

[karrtikr]

For instance, this is my Python test log,

================================== FAILURES ===================================
_______________________ FailingTests.test_failure_still _______________________

self = <hello_test.FailingTests testMethod=test_failure_still>

    def test_failure_still(self):
>       self.assertEqual("I'm right!", "no, I am!")
E       AssertionError: "I'm right!" != 'no, I am!'
E       - I'm right!
E       + no, I am!

Tests\steve\hello_test.py:6: AssertionError
- generated xml file: C:\Users\karraj\AppData\Local\Temp\tmp-4172kPl1yrfyWOkV.xml -
============================== 1 failed in 0.12s ==============================

Have a look at this string which appears in the traceback: "Tests\steve\hello_test.py:6: AssertionError". We are separating on ":" to get the relative path to the test file Tests\steve\hello_test.py. I am suspecting you have the absolute path appearing here, and we expect relative paths in Pytest output after running the file.

In my case the following command was used to run the test file - which gives relative paths to root directory (Double check this with pytest-dev/pytest#7463)

C:\Users\karraj\AppData\Local\Programs\Python\Python37\python.exe c:\Users\karraj\Desktop\vscode-python\pythonFiles\pyvsc-run-isolated.py pytest --override-ini junit_family=xunit1 --rootdir c:\Users\karraj\Desktop\Desktop\test_demo --junit-xml=C:\Users\karraj\AppData\Local\Temp\tmp-41724BpAkWghx9dx.xml Tests/steve

What's the command you see in your Python output panel? Can you please try running the command in terminal and checking the output?

Maybe Pytest returns absolute paths in case of mounted drives?

[karrtikr]

Anyways, the fix seems clear enough. Don't expect only relative paths at this line and do a file exists check before opening document.

[Almenon]

I believe this is a duplicate of #10658 - both issues report the same bug with not being able to open a file and in the output both of the paths have a c at the end.

Given that the other issues has more 👍 can we close this issue please? I can post @karrtikr 's comment on the other issue explaining how it needs to be fixed.

[IBestuzhev]

There is super-weird workaround (Windows 10) that I use now, hope this will be fixed in the repo soon.

But if you want to use pytest now, you can do the following.

Go to settings and add a line to Python > Testing: Pytest Args:

--junit-xml=./project-name-tests/results.xml

After that use elevated Power Shell to create a Junction from root of your disk to this subfolder:

cd /
New-Item -Type Junction -Path ./project-name-tests/ -Target .\Path\To\Working\Dir\project-name-tests\

---

What happens here?

I guess the main problem is that Windows paths are not detected correctly as absolute paths. So test runner tries to read C:\your\project\dir\C:\path\to\temp\file.xml and fails.

However if XML file is generated under your project folder, there is another bug 😫 And it makes test runner to try to open C:\subfolder\file.xml (I guess it's not always C: drive, but the drive you are using for your code).

So this junction point creates a link from C:\subfolder\ to C:\path\to\project\subfolder and the file is now readable even on incorrect path.

[ChadBailey]

+1 for me, sadly.

Update: I originally attributed my woes to a particular plugin I installed, but it's looking like that's unrelated. Still working on steps to easily reproduce.

[ChadBailey]

Wow, this was so incredibly obscure (for me). I've finally come up with a minimal way to reproduce this bug!

Steps to reproduce

1. Install a fresh environment with pytest. I made a folder named vscode_python_12403 and used pipenv: pipenv install --dev pytest
2. Create a file, test_12403.py
3. Paste the following code into the file

Method 1

from datetime import datetime

def test_expected_behavior():
    # Test fails, but fails in the way we expect both tests to fail
    data_string = '2021'
    format = '%Y-'
    raise ValueError("time data %r does not match format %r" %
                    (data_string, format))

def test_unexpected_behavior():
    # Test fails, but this time it causes the unexpected behavior in 12403
    datetime.strptime('2021', '%Y-')

Method 2 (uses a monkeypatch to isolate further than before)

from datetime import datetime

class MockTime(datetime):
    @classmethod
    def strptime(cls, data_string, format):
        raise ValueError("time data %r does not match format %r" %
                        (data_string, format))

def test_12403():
    # Test fails, but fails in the way we expect (resolves bug)
    # Comment this line out to reproduce 12403.
    datetime = MockTime
    datetime.strptime('2021', '%Y-')

4. Click python interpreter on bottom-left and select the venv that pipenv generated
5. Configure tests.
   a. Open command pallete with Ctrl+Shift+P
   b. Enter Python: Configure Tests and click
   c. Click pytest
   d. Click . Root directory
6. Run tests and observe behavior.

[rvanlaar]

I ran into the same error under linux. The path it was searching for was wrong.
What happened was that my pycache files were originally in another directory (due to docker mounts). Removing the all the pycaches resolved the issue. Under linux I executed: find ./ -name "__pycache__" -exec rm -rf {} \+

[yurigene]

I have same error when running pytest.
The tests are discoverable and I'm able to run them, but when I 'm running the test in output I see error: "cannot open file:///Users/yurib/Projects/files_uploader/tests/test_system_tests_linux.py"

Worth to mention that previously I moved the project to the new path and in the error vscode somehow refers to the old path of the test file. I tried to clear the cache, deleted python extension, but still same error.

====> MY ISSUE SOLVED by deleting cache files inside tests directory

[rulerofthehuns]

Another way to reproduce:

Create test_main.py with contents:

import unittest
import unittest.mock

class TestCrash(unittest.TestCase):
    def test_simple(self):
        m2 = unittest.mock.Mock(name='mymock')
        # m2() # no error if this is called
        m2.assert_called()

Setup testrunner:

• run command 'Python: Configure Tests'
• select 'pytest'
• select '. Root directory'

Run all tests

• 'There was an error running the tests' notification is displayed
• 'Python Test Log' output ends with an error message:

Error: Error: cannot open file:///d%3A/dev/py/1/c. Detail: Unable to read file 'd:\dev\py\1\c' (Error: Unable to resolve non-existing file 'd:\dev\py\1\c')

If I create the missing file ('d:\dev\py\1\c'), the error message is replaced:

Error: Error: Illegal value for `line`

Notes:

My testing environment:

VSCode: 1.58.1
pytest version: 6.2.4
python: 3.7.2
python extension: v2021.6.944021595

The error occurs every time on windows, I've only managed to reproduce it in WSL once.
Deleting pycache fixed WSL, no visible effect on windows.

[MikeWise2718]

Am also getting this error, seems to have not been resolved although it is reproducable and the issue was raised over a year ago. I guess I can go back to using test.http

[luabud]

I was able to reproduce this error using the stable build, and verified that #16769 will fix it 😊

[rulerofthehuns]

The issue can still be reproduced with the steps in my previous comment:
#12403 (comment)

[luabud]

@rulerofthehuns the issue is still occurring on the stable version of the Python extension but it should be fixed in the next release. It's also now available in our insiders program (View > Command Palette... and run "Python: Switch to Insiders Weekly Channel")

[rulerofthehuns]

@luabud Thank you for the clarification. I've assumed the python extension was also updated with VSCode's update, and didn't check the version.
I can confirm that the bug cannot be reproduced with the new version.