如果你使用VS Code，并且你的测试与你的项目位于同一级别，那么运行和调试你的代码就不能开箱即用。你能做的就是改变启动方式。json文件:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python",
            "type": "python",
            "request": "launch",
            "stopOnEntry": false,
            "pythonPath": "${config:python.pythonPath}",
            "program": "${file}",
            "cwd": "${workspaceRoot}",
            "env": {},
            "envFile": "${workspaceRoot}/.env",
            "debugOptions": [
                "WaitOnAbnormalExit",
                "WaitOnNormalExit",
                "RedirectOutput"
            ]
        }    
    ]
}

这里的关键行是envFile

"envFile": "${workspaceRoot}/.env",

在项目的根目录中添加.env文件

在.env文件中添加项目根目录的路径。这将临时添加

PYTHONPATH = C: \ \ PYTHON项目\ \ ROOT_DIRECTORY

路径到你的项目，你将能够使用调试单元测试从VS Code

使用setup.py develop使您的工作目录成为已安装的Python环境的一部分，然后运行测试。

如果没有一些巫术，就不能从父目录导入。下面是另一种至少适用于Python 3.6的方法。

首先，创建一个包含以下内容的test/context.py文件:

import sys
import os
sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

然后在test/test_antigravity.py文件中导入如下内容:

import unittest
try:
    import context
except ModuleNotFoundError:
    import test.context    
import antigravity

请注意，这个try-except子句的原因是

导入测试。当使用“python test_antigravity.py”运行时，上下文将失败 在new_project目录下使用"python -m unittest"运行时导入context失败。

通过这种诡计，他们都成功了。

现在你可以运行test目录下的所有测试文件:

$ pwd
/projects/new_project
$ python -m unittest

或者运行一个单独的测试文件:

$ cd test
$ python test_antigravity

好吧，这并不比在test_antigravity。py中包含context。py的内容漂亮多少，但也许会漂亮一点。欢迎提出建议。

同样的问题我已经有很长时间了。我最近选择的目录结构是这样的:

project_path
├── Makefile
├── src
│   ├── script_1.py
│   ├── script_2.py
│   └── script_3.py
└── tests
    ├── __init__.py
    ├── test_script_1.py
    ├── test_script_2.py
    └── test_script_3.py

在test文件夹的__init__.py脚本中，我写了以下内容:

import os
import sys
PROJECT_PATH = os.getcwd()
SOURCE_PATH = os.path.join(
    PROJECT_PATH,"src"
)
sys.path.append(SOURCE_PATH)

对于共享项目来说，Makefile非常重要，因为它强制正确地运行脚本。下面是我放在Makefile中的命令:

run_tests:
    python -m unittest discover .

The Makefile is important not just because of the command it runs but also because of where it runs it from. If you would cd in tests and do python -m unittest discover ., it wouldn't work because the init script in unit_tests calls os.getcwd(), which would then point to the incorrect absolute path (that would be appended to sys.path and you would be missing your source folder). The scripts would run since discover finds all the tests, but they wouldn't run properly. So the Makefile is there to avoid having to remember this issue.

我真的很喜欢这种方法，因为我不需要触及我的src文件夹，我的单元测试或我的环境变量，一切都运行顺利。

如果您正在寻找命令行解决方案:

基于以下目录结构(使用专用源目录进行概括):

new_project/
    src/
        antigravity.py
    test/
        test_antigravity.py

Windows:(在new_project中)

$ set PYTHONPATH=%PYTHONPATH%;%cd%\src
$ python -m unittest discover -s test

如果您想在批for循环中使用此语句，请参阅此问题。

Linux:(在new_project中)

$ export PYTHONPATH=$PYTHONPATH:$(pwd)/src  [I think - please edit this answer if you are a Linux user and you know this]
$ python -m unittest discover -s test

使用这种方法，还可以在必要时向PYTHONPATH添加更多目录。

从你链接的文章中:

Create a test_modulename.py file and put your unittest tests in it. Since the test modules are in a separate directory from your code, you may need to add your module’s parent directory to your PYTHONPATH in order to run them: $ cd /path/to/googlemaps $ export PYTHONPATH=$PYTHONPATH:/path/to/googlemaps/googlemaps $ python test/test_googlemaps.py Finally, there is one more popular unit testing framework for Python (it’s that important!), nose. nose helps simplify and extend the builtin unittest framework (it can, for example, automagically find your test code and setup your PYTHONPATH for you), but it is not included with the standard Python distribution.

也许你应该像它所暗示的那样看看鼻子?