Unable to use test discovery for Django tests

[interDist]

Type: Bug

Behaviour

Test discovery fails for my Django project. In fact, I have never managed to get it to work, but there is an evolution of errors. Currently, the following appears in the Output:

Discovering unittest tests for workspace /homedir/[REDACTED] with arguments: /homedir/.vscode/extensions/ms-python.python-2025.7.2025060501-linux-x64/python_files/unittestadapter/discovery.py,--udiscovery,-v,-s,./tests,-p,test_*.py

 ~/venvs/p312/bin/python ~/.vscode/extensions/ms-python.python-2025.7.2025060501-linux-x64/python_files/unittestadapter/discovery.py --udiscovery -v -s ./tests -p test_*.py
MANAGE_PY_PATH is set, running Django discovery with path to manage.py as: $/homedir/[REDACTED]/manage.py
Running Django tests with command: ['/homedir/venvs/p312/bin/python', '/homedir/[REDACTED]/manage.py', 'test', '--testrunner=django_test_runner.CustomDiscoveryTestRunner', '-v', '-s', './tests', '-p', 'test_*.py']

manage.py test: error: argument -v/--verbosity: expected one argument

Django test discovery process exited with non-zero error code 

GitHub Copilot says the following about all this: "Recent versions of the VSCode Python extension ignore python.testing.unittestArgs for test discovery in the Testing tab. This is a known issue and limitation: the Testing tab always uses its own discovery logic and ignores custom arguments. See: VSCode Python extension issue #18309".

Steps to reproduce:

1. Use venv to setup a new virtual environment with Python 3.12
2. Create a new Django project
3. Create the subfolder "tests" and place some unit tests there
4. Observe that ./manage.py test runs those
5. Observe the errors detailed above when trying to refresh tests in the Testing tab in VSCode

Diagnostic data

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

See above

Extension version: 2025.7.2025060501
VS Code version: Code 1.100.3 (258e40fedc6cb8edf399a463ce3a9d32e7e1f6f3, 2025-06-02T13:30:54.273Z)
OS version: Linux x64 6.11.0-26-generic snap
Modes:

• Python version (& distribution if applicable, e.g. Anaconda): 3.12.3
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Venv
• Value of the python.languageServer setting: Default

User Settings

venvPath: "<placeholder>"

languageServer: "Pylance"

testing
• unittestArgs: "<placeholder>"
• unittestEnabled: true

Installed Extensions

Extension Name	Extension Id	Version
autodocstring	njp	0.6.1
copilot	Git	1.333.0
copilot-chat	Git	0.27.3
debugpy	ms-	2025.9.2025053001
django-gettext	xia	1.0.2
docker	doc	0.10.0
even-better-toml	tam	0.21.2
js-debug	ms-	1.100.1
js-debug-companion	ms-	1.1.3
jupyter	ms-	2025.3.2025032101
jupyter-keymap	ms-	1.1.2
jupyter-renderers	ms-	1.1.2025012901
python	ms-	2025.7.2025060501
python-environment-manager	don	1.2.7
remote-containers	ms-	0.418.0
remote-explorer	ms-	0.5.0
remote-server	ms-	1.5.2
remote-ssh	ms-	0.120.0
remote-ssh-edit	ms-	0.87.0
remote-wsl	ms-	0.99.0
ruff	cha	2025.22.0
vscode-containers	ms-	2.0.3
vscode-django	bat	1.15.0
vscode-docker	ms-	2.0.0
vscode-github-actions	git	0.27.2
vscode-js-profile-table	ms-	1.0.10
vscode-jupyter-cell-tags	ms-	0.1.9
vscode-jupyter-slideshow	ms-	0.1.6
vscode-pylance	ms-	2025.5.103
vscode-remote-extensionpack	ms-	0.26.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (4 x 0)
GPU Status	2d_canvas: unavailable_software canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: disabled_software multiple_raster_threads: enabled_on opengl: disabled_off rasterization: disabled_software raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: disabled_software video_encode: disabled_software vulkan: disabled_off webgl: unavailable_software webgl2: unavailable_software webgpu: disabled_off webnn: unavailable_software
Load (avg)	2, 2, 1
Memory (System)	7.71GB (2.35GB free)
Process Argv	--no-sandbox --force-user-env --crash-reporter-id 8be4dee1-8ffe-4e7f-b715-5b8d68766f73
Screen Reader	no
VM	100%
DESKTOP_SESSION	ubuntu
XDG_CURRENT_DESKTOP	Unity
XDG_SESSION_DESKTOP	ubuntu
XDG_SESSION_TYPE	wayland

A/B Experiments

vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805cf:30301675
binariesv615:30325510
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
h48ei257:31000450
pythontbext0:30879054
cppperfnew:31000557
dwnewjupytercf:31046870
pythonrstrctxt:31112756
nativeloc2:31192216
5fd0e150:31155592
dwcopilot:31170013
6074i472:31201624
dwoutputs:31242946
customenabled:31248079
9064b325:31222308
copilot_t_ci:31222730
e5gg6876:31282496
pythoneinst12:31285622
bgtreat:31268568
4gafe986:31271826
c7cif404:31314491
996jf627:31283433
pythonrdcb7:31303018
usemplatestapi:31297334
0aa6g176:31307128
7bj51361:31289155
747dc170:31275177
pylancecolor:31314202
aj953862:31281341
generatesymbolt:31295002
convertfstringf:31295003
gendocf:31295004
pylancequickfixf:31319675
he899328:31327032
b6b4d950:31327385

[eleanorjboyd]

Do you have any args in your settings under python.unittest.args? I don't think I append -v and did a code check and didn't find it through that look either

[interDist]

Your question made me question my settings. All of them are in settings.json under my home dir, but I did just find another settings.json inside the project directory (in the .vscode subfolder). I definitely did not create it myself, and did not even know it is there. Maybe when I clicked “Configure Python Tests”, VSCode created it?

After commenting out everything related to tests in that extra file, the unittest arguments I specify manually in the main settings file are now picked up. I can finally use test discovery!

I suppose on your side it is worth a look into the “Configure Python Tests” process and why it generates an invalid set of argument.

[eleanorjboyd]

So what I think happens is the Django settings are shared with unittest (because unittest runs Django tests) and so the argument is a unittest arg but not a Django arg. We contribute the unittest setting as you set up unittest (and select it as your testing settings). This is a great point that this behavior should probably be removed as they aren't applicable for Django.

@cwebster-99 what do you think about switching so unittest no longer sets basic settings? What we are adding to the unittest - settings is -v -s ./tests -p "test_*.py" right now and I would want to remove that. Here are the things it impacts:

• Verbose output vs. basic output
• Specific test folder vs. default current directory (ie would have trouble finding tests)
• Looser filename pattern (test_.py vs. test.py so existing tests should still fit the pattern and just widen the funnel)

[cwebster-99]

@eleanorjboyd can you speak more to the impact of

Specific test folder vs. default current directory (ie would have trouble finding tests)

Do we foresee an increase in discovery failure or just longer discovery duration?

[github-actions]

Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on, then we will be happy to re-open this issue to pick up where we left off.

Happy Coding!

[raigu]

Found this issue when having the same trouble.

When you use "Python: Configure Tests", it overwrites python.testing.unittestArgs in settings.json. If you tweaked something and tried to configure again, your previous settings get silently replaced—causing confusing failures when you assume your values are still applied.

For me the solution was to configure Django testing manually as described in the documentation 😇 . The documentation also mentions python.testing.unittestArgs:

Add Django test arguments to "python.testing.unittestArgs": [] in the settings.json file as needed, 
and remove any arguments that are not compatible with Django.

BTW, if your tests use databases you probably want "python.testing.unittestArgs": ["--noinput"]. It skips the confirmation prompt for creating the test database—which can hang waiting for input without making it obvious that your response is needed.