1. 如果使用一个指定UnitTests应该在哪里生存的库,
2. 在小项目的模块中,或
3. 在一个 tests/ 用于大型项目的包中的子目录。

关键是什么对你正在创建的项目最有效。

有时,您使用的库会确定测试应该去哪里,Django的情况也是如此(您将测试放在哪里) models.py ,请 tests.py 或者 试验/ 应用程序中的子目录)。

如果没有现有的限制,这是个人偏好的问题。对于一小部分模块,将UnitTests放入您正在创建的文件中可能更方便。

对于超过几个模块的任何内容,我都在 试验/ 包中的目录。将测试代码与实现混合在一起会给任何阅读代码的人增加不必要的干扰。

是的,请使用单独的模块。

使用 __main__ 诡计。假设你有 几个文件 在您的模块中,它不再工作,因为 您不想运行每个源文件 在测试模块时单独进行。

此外,在安装模块时,大多数情况下 您不想安装测试 . 您的最终用户不关心测试,只有开发人员才应该关心。

不,真的。把你的测试放进去 tests/ 你的医生 doc 准备好一个makefile make test . 任何其他方法都只是中间解决方案,只对特定的小模块有效。

就我个人而言,我在源目录中创建了一个测试/文件夹,并尝试或多或少地用单元测试等价物(1个模块=1个单元测试模块作为经验法则)镜像我的主源代码层次结构。

注意我正在使用 nose 它的哲学和UnitTest有点不同。

我通常将测试代码保存在一个单独的模块中,并将模块/包和测试发送到一个分发版中。如果用户安装时使用 setup.py 他们可以从测试目录运行测试,以确保所有东西都在他们的环境中工作,但是只有模块的代码在 Lib/site-packages .

除了测试使用 if __name__ == '__main__' 检查。将测试保存在其他模块中会使该选项对您开放。另外,如果您重构了一个模块的实现,并且您的测试位于另一个未编辑的模块中,那么当您根据重构的代码运行这些测试时,您就知道它们没有被更改。

我通常把它们放在一个单独的文件夹里 试验/ . 就我个人而言,我不使用if_uu name_uuu='uuu main_uuu'检查,因为我使用鼻测试,它自己处理测试检测。

if __name__ == '__main__' 等对于小测试是很好的。