只有一个测试文件

如果只有1个测试文件，建议将其放在顶级目录中:

module/
    lib/
        __init__.py
        module.py
    test.py

在CLI下运行测试

python test.py

许多测试文件

如果有很多测试文件，将其放在tests文件夹中:

module/
    lib/
        __init__.py
        module.py
    tests/
        test_module.py
        test_module_function.py

# test_module.py

import unittest
from lib import module

class TestModule(unittest.TestCase):
    def test_module(self):
        pass

if __name__ == '__main__':
    unittest.main()

在CLI下运行测试

# In top-level /module/ folder
python -m tests.test_module
python -m tests.test_module_function

使用单元测试发现

单元测试发现将在包文件夹中找到所有测试。

在tests/文件夹中创建__init__.py

module/
    lib/
        __init__.py
        module.py
    tests/
        __init__.py
        test_module.py
        test_module_function.py

在CLI下运行测试

# In top-level /module/ folder

# -s, --start-directory (default current directory)
# -p, --pattern (default test*.py)

python -m unittest discover

参考

用于测试布局的pytest良好实践 unittest

单元测试框架

鼻子 nose2 pytest

我们在编写为Python程序生成单元测试的Pythoscope (https://pypi.org/project/pythoscope/)时遇到了同样的问题。在我们选择目录之前，我们对python列表中的测试进行了民意调查，有很多不同的意见。最后，我们选择将“tests”目录放在与源代码相同的目录中。在该目录中，我们为父目录中的每个模块生成一个测试文件。

我将测试放在与测试代码(CUT)相同的目录中。在项目中，我可以用我的插件调整pytest，对于foo.py，我使用foo.pt进行测试，这使得编辑特定的模块及其测试非常容易:vi foo.*。

在不能这样做的地方，我使用foo_ut.py或类似的方法。你仍然可以使用vi foo*，尽管它也会捕获foobar.py和foobar_ut.py(如果它们存在的话)。

在这两种情况下，我调整测试发现过程来找到这些。

这将测试放在目录列表中代码的旁边，使测试明显地存在于那里，并使打开测试尽可能容易，当它们位于单独的文件中时。(对于从命令行开始的编辑器，如上所述;对于GUI系统，单击代码文件和相邻的(或非常接近相邻的)测试文件。

正如其他人所指出的，这也使得重构和提取代码以供在其他地方使用变得更容易。

I really dislike the idea of putting tests in a completely different directory tree; why make it harder than necessary for developers to open up the tests when they're opening the file with the CUT? It's not like the vast majority of developers are so keen on writing or tweaking tests that they'll ignore any barrier to doing that, instead of using the barrier as an excuse. (Quite the opposite, in my experience; even when you make it as easy as possible I know many developers who can't be bothered to write tests.)

我不相信存在既定的“最佳实践”。

我把我的测试放在应用程序代码之外的另一个目录中。然后，我将主应用程序目录添加到sys。路径(允许您从任何地方导入模块)在我的测试运行脚本(它也做一些其他的事情)之前运行所有的测试。这样，当我发布主代码时，我就不必从主代码中删除测试目录，节省了我的时间和精力，即使时间和精力非常少。

When writing a package called "foo", I will put unit tests into a separate package "foo_test". Modules and subpackages will then have the same name as the SUT package module. E.g. tests for a module foo.x.y are found in foo_test.x.y. The __init__.py files of each testing package then contain an AllTests suite that includes all test suites of the package. setuptools provides a convenient way to specify the main testing package, so that after "python setup.py develop" you can just use "python setup.py test" or "python setup.py test -s foo_test.x.SomeTestSuite" to the just a specific suite.

我更喜欢顶层测试目录。这确实意味着进口变得更加困难。对此，我有两个解决方案:

使用setuptools。然后你可以将test_suite='tests.runalltests.suite'传递给setup()，并可以简单地运行测试 在运行测试时设置PYTHONPATH: PYTHONPATH=。python测试/ runalltests.py

下面是M2Crypto中的代码是如何支持这些东西的:

http://svn.osafoundation.org/m2crypto/trunk/setup.py http://svn.osafoundation.org/m2crypto/trunk/tests/alltests.py

如果您更喜欢使用鼻子测试运行测试，则可能需要做一些不同的事情。