如果你正在编写一个库或应用程序,那么单元测试文件应该放在哪里?
将测试文件与主应用程序代码分开是很好的,但将它们放在应用程序根目录中的“tests”子目录中是很尴尬的,因为这会使导入将要测试的模块变得更加困难。
这里是否存在最佳实践?
如果你正在编写一个库或应用程序,那么单元测试文件应该放在哪里?
将测试文件与主应用程序代码分开是很好的,但将它们放在应用程序根目录中的“tests”子目录中是很尴尬的,因为这会使导入将要测试的模块变得更加困难。
这里是否存在最佳实践?
当前回答
一种常见的做法是将测试目录放在与模块/包相同的父目录中。因此,如果你的模块名为foo.py,你的目录布局将如下所示:
parent_dir/
foo.py
tests/
当然,没有一种方法可以做到这一点。您还可以创建一个tests子目录,并使用绝对导入导入模块。
无论您在哪里进行测试,我都建议您使用nose来运行它们。Nose在您的目录中搜索测试。这样,您就可以把测试放在组织上最有意义的地方。
其他回答
我将测试放在与测试代码(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。路径(允许您从任何地方导入模块)在我的测试运行脚本(它也做一些其他的事情)之前运行所有的测试。这样,当我发布主代码时,我就不必从主代码中删除测试目录,节省了我的时间和精力,即使时间和精力非常少。
在c#中,我通常将测试分离到单独的程序集中。
在Python中——到目前为止——我倾向于编写doctests,其中测试位于函数的文档字符串中,或者将它们放在模块底部的if __name__ == "__main__"块中。
根据我用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打包这些库时,您可以只打包主库模块(仅)。这有助于可维护性,特别是在敏捷环境中。
我们使用
app/src/code.py
app/testing/code_test.py
app/docs/..
在每个测试文件中,我们插入../src/ sys.path。这不是最好的解决办法,但很有效。我认为如果有人提出类似java中的maven之类的东西,给你提供标准的约定,无论你在做什么项目,都可以工作,那就太好了。