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

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

一种常见的做法是将测试目录放在与模块/包相同的父目录中。因此，如果你的模块名为foo.py，你的目录布局将如下所示:

parent_dir/
  foo.py
  tests/

当然，没有一种方法可以做到这一点。您还可以创建一个tests子目录，并使用绝对导入导入模块。

无论您在哪里进行测试，我都建议您使用nose来运行它们。Nose在您的目录中搜索测试。这样，您就可以把测试放在组织上最有意义的地方。

我最近开始用Python编程，所以我还没有机会找到最佳实践。 但是，我已经写了一个模块，它可以找到所有的测试并运行它们。

所以，我有:

app/
 appfile.py
test/
 appfileTest.py

当我进入更大的项目时，我得看看情况如何。

我使用tests/目录，然后使用相对导入导入主要应用程序模块。在MyApp/tests/foo.py中，可能有:

from .. import foo

导入MyApp。foo模块。

在c#中，我通常将测试分离到单独的程序集中。

在Python中——到目前为止——我倾向于编写doctests，其中测试位于函数的文档字符串中，或者将它们放在模块底部的if __name__ == "__main__"块中。

对于文件module.py，单元测试通常应该被称为test_module.py，遵循python命名约定。

test_module.py有几个常用的存放位置:

和module.py在同一个目录下。 在../tests/test_module.py中(与代码目录处于同一级别)。 在tests/test_module.py中(代码目录下的一级)。

我更喜欢#1，因为它很容易找到测试并导入它们。无论您使用什么构建系统，都可以轻松地配置为运行以test_开头的文件。实际上，用于测试发现的默认单元测试模式是test*.py。

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.

如果测试很简单，就把它们放在文档字符串中——大多数Python测试框架都可以使用它:

>>> import module
>>> module.method('test')
'testresult'

对于其他更复杂的测试，我将它们放在../tests/test_module.py或tests/test_module.py中。

我也倾向于把我的单元测试放在文件本身中，正如Jeremy Cantrell上面所指出的，尽管我倾向于不把测试函数放在主体中，而是把所有东西都放在一个文件中

if __name__ == '__main__':
   do tests...

块。这最终会将文档添加到文件中，作为如何使用您正在测试的python文件的“示例代码”。

我应该补充一点，我倾向于编写非常紧凑的模块/类。如果你的模块需要大量的测试，你可以把它们放在另一个测试中，但即使这样，我仍然会补充:

if __name__ == '__main__':
   import tests.thisModule
   tests.thisModule.runtests

这让任何阅读源代码的人都知道到哪里去寻找测试代码。

我们使用

app/src/code.py
app/testing/code_test.py 
app/docs/..

在每个测试文件中，我们插入../src/ sys.path。这不是最好的解决办法，但很有效。我认为如果有人提出类似java中的maven之类的东西，给你提供标准的约定，无论你在做什么项目，都可以工作，那就太好了。

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

使用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

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

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

我是怎么做的…

文件夹结构:

project/
    src/
        code.py
    tests/
    setup.py

Setup.py指向src/作为包含我的项目模块的位置，然后运行:

setup.py develop

它将我的项目添加到站点包中，指向我的工作副本。要运行测试，我使用:

setup.py tests

使用我配置的任何测试运行程序。

根据我用Python开发测试框架的经验，我建议将Python单元测试放在一个单独的目录中。维护对称的目录结构。这将有助于只打包核心库，而不打包单元测试。下面是通过原理图实现的。

                              <Main Package>
                               /          \
                              /            \
                            lib           tests
                            /                \
             [module1.py, module2.py,  [ut_module1.py, ut_module2.py,
              module3.py  module4.py,   ut_module3.py, ut_module.py]
              __init__.py]

通过这种方式，当您使用rpm打包这些库时，您可以只打包主库模块(仅)。这有助于可维护性，特别是在敏捷环境中。

只有一个测试文件

如果只有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

我建议你在GitHub上查看一些主要的Python项目，并获得一些想法。

当你的代码变大，你添加了更多的库，最好在你有setup.py的同一个目录下创建一个测试文件夹，并为每种测试类型镜像你的项目目录结构(unittest, integration，…)

例如，如果你有一个这样的目录结构:

myPackage/
    myapp/
       moduleA/
          __init__.py
          module_A.py
       moduleB/
          __init__.py
          module_B.py
setup.py

添加测试文件夹后，您将拥有如下目录结构:

myPackage/
    myapp/
       moduleA/
          __init__.py
          module_A.py
       moduleB/
          __init__.py
          module_B.py
test/
   unit/
      myapp/
         moduleA/
            module_A_test.py
         moduleB/
            module_B_test.py
   integration/
          myapp/
             moduleA/
                module_A_test.py
             moduleB/
                module_B_test.py
setup.py

许多正确编写的Python包使用相同的结构。Boto包就是一个很好的例子。 检查https://github.com/boto/boto

每隔一段时间，我发现自己检查了测试放置的主题，每次大多数人都建议在库代码旁边使用单独的文件夹结构，但我发现每次的论点都是一样的，而且没有那么令人信服。我最终把我的测试模块放在核心模块旁边的某个地方。

这样做的主要原因是:重构。

当我移动东西时，我确实希望测试模块与代码一起移动;如果测试位于单独的树中，则很容易丢失测试。说实话，迟早你会得到一个完全不同的文件夹结构，就像django, flask和其他的一样。如果你不在乎也没关系。

你应该问自己的主要问题是:

我在写:

A)可重复使用的库或 B)构建一个项目，而不是将一些半分离的模块捆绑在一起?

如果一个:

单独的文件夹和额外的维护其结构的工作可能更适合。没有人会抱怨将测试部署到生产环境中。

但是，当测试与核心文件夹混合在一起时，也很容易将它们排除在分发之外;把这个放到setup.py中:

find_packages("src", exclude=["*.tests", "*.tests.*", "tests.*", "tests"]) 

如果b:

您可能希望—正如我们每个人都希望—您正在编写可重用的库，但是大多数时候它们的生命与项目的生命紧密相连。能够轻松地维护您的项目应该是优先考虑的。

然后，如果你做得很好，你的模块很适合另一个项目，它可能会被复制到这个新项目中，而不是被分叉或被做成一个单独的库，并且与在一个单独的测试文件夹中搜索测试相比，在相同的文件夹结构中移动放在它旁边的测试很容易。(你可能会说，它一开始就不应该一团糟，但让我们现实一点)。

所以选择仍然是你的，但我认为混合测试可以实现与单独文件夹相同的功能，但在保持文件整洁方面花费的精力更少。

我将测试放在与测试代码(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.)