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

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

这里是否存在最佳实践?


当前回答

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

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

其他回答

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

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

只有一个测试文件

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

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

parent_dir/
  foo.py
  tests/

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

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

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

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

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

我们使用

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

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