Unit tests aren't discovered in sub-folders

Environment data

• VS Code version: 1.45.1
• Extension version (available under the Extensions sidebar): 2020.5.80290
• OS and version: Arch Linux (kernel: linux 5.6.14.arch1-1)
• Python version (& distribution if applicable, e.g. Anaconda): Python 3.8.3 64-bit
• Type of virtual environment used (N/A | venv | virtualenv | conda | …): pipenv
• Relevant/affected Python packages and their versions: unittest
• Relevant/affected Python-related VS Code extensions and their versions: None
• Jedi or Language Server? (i.e. what is "python.jediEnabled" set to; more info #3977): True
• Value of the python.languageServer setting: Microsoft

Actual behaviour

In main tests/ directory are some tests and some other files needed. Those work fine until a subdirectory is created, which contains 2 tests named test_decorators.py and test_pagination.py, this subdirectory also contains the __init__.py so that the tests can be recognized. After this subdirectory is created, the tests from main directory (tests/) disappear and the ones from subdirectory are not displayed either, a popup saying that no tests were discovered and asking me to configure the test framework (It is configured properly)

Once the __init__.py file is added and I rediscover the tests, this box pops up.

Expected behaviour

When I add the subdirectory to main tests/ directory and search for the tests, both the tests from my main directory and the subdirectory should be found.

Steps to reproduce:

1. Create directory for tests in root of your project tests/
2. Configure the framework to use unittests and recognise files labeled: test_*.py
3. Add some tests in it and let the framework discover them [To this point everything is as expected]
4. Add a subdirectory in your tests/ directory and place some other tests in it
5. Run test discovery again
6. No tests were found

Logs

Output from Console under the Developer Tools panel (toggle Developer Tools on under Help; turn on source maps to make any tracebacks be useful by running Enable source map support for extension debugging)

[Extension Host] Info Python Extension: 2020-05-24 16:13:27: getActivatedEnvironmentVariables, Class name = E, completed in 1ms, has a truthy return value, Arg 1: <Uri:/home/itsdrike/Programming/Python/Projects/Discord-Bot>, Arg 2: undefined, Arg 3: undefined

[Extension Host] Info Python Extension: 2020-05-24 16:13:27: > ~/.local/share/virtualenvs/Discord-Bot-j5RKKR3Y/bin/python -c "import unittestloader = unittest.TestLoader()suites = loader.discover("./tests", pattern="test_*.py")print("start") #Don't remove this linefor suite in suites._tests:    for cls in suite._tests:        try:            for m in cls._tests:                print(m.id())        except:            pass"

[Extension Host] Info Python Extension: 2020-05-24 16:13:27: cwd: ~/Programming/Python/Projects/Discord-Bot

[ItsDrike]

Any progress on this?

I have came back to this page for about ten times, but nothing changed… This bug makes the unittest function of this plugin almost useless. I have already disable it in my projects…

Yeah, unit-testing doesn’t work at all, I think this should have higher priority than it does now since testing is a very important part of every bigger python project and it’s quite rare to have all of the tests in the same directory, not detecting this automatically is a pretty big issue, why is it taking so long to fix?

It’s already been over 5 months since I’ve opened the issue and frankly, that’s just unacceptable for an issue like this. I believe I’ve done an okay job documenting it and providing enough details about it although I can give you more details if you need them.

I don’t often push on issues being fixed, but considering it was almost half of a whole year that has already passed, I’d really appreciate it if you looked into this a little further @ericsnowcurrently

[ericsnowcurrently]

Yeah, that second command (from the log file) is actually multi-line:

~/.local/share/virtualenvs/Discord-Bot-j5RKKR3Y/bin/python -c '
import unittest
loader = unittest.TestLoader()
suites = loader.discover("./tests", pattern="test_*.py")
print("start")
for suite in suites._tests:
    for cls in suite._tests:
        for m in cls._tests:
            print(m.id())
'

The big question is if the two command actually are equivalent. I’m thinking they actually aren’t. The “top_level_dir” argument to loader.discover() wasn’t passed in the logged script. It defaults to the start dir (“./tests”), which I expect makes the tests fail. The equivalent command would be ~/.local/share/virtualenvs/Discord-Bot-j5RKKR3Y/bin/python -m unittest discover -p 'test_*.py' -s './tests' (note the missing -t arg). What happens when you run that?