如果你正在编写一个库或应用程序,那么单元测试文件应该放在哪里?

将测试文件与主应用程序代码分开是很好的,但将它们放在应用程序根目录中的“tests”子目录中是很尴尬的,因为这会使导入将要测试的模块变得更加困难。

这里是否存在最佳实践?


当前回答

我们使用

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

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

其他回答

根据我用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打包这些库时,您可以只打包主库模块(仅)。这有助于可维护性,特别是在敏捷环境中。

我是怎么做的…

文件夹结构:

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

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

setup.py develop

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

setup.py tests

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

我建议你在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:

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

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

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

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

from .. import foo

导入MyApp。foo模块。