2

我有一些团结正在做类似的事情：

_files = ('test1.txt','test2.txt'......)
setUp(){
    //create test files

    for f in _files:
        f = open(f, 'w')
        f.close()
}
tearDown(){
    for f in _files:
    if os.path.exists(f):
        os.remove(f)
}

但是有些人告诉我，在 unitest 中执行 I/O 不是一个好习惯，是真的吗？

4

2 回答 2

7

但是有些人告诉我，在 unitest 中执行 I/O 不是一个好习惯，是真的吗？

我认为在单元测试中执行 I/O 不一定是坏事。

唯一需要注意的是，如果您的单元测试依赖于一些预先存在的数据文件来完成它的工作，那么这些文件应该被视为单元测试的一部分（因此是版本控制等）。

PS你有没有试过询问那些给你这个建议的人，因为建议背后的具体原因？

于 2012-05-30T18:12:21.490 回答
0

一般来说，编写测试的最佳实践是只有在没有产生预期行为时才会失败。

如果您包含任何第三方代码或除您的测试方法之外的逻辑，即使测试方法工作正常，您也会添加测试失败的原因。在单元测试中，您使用模拟来替换其他对象或方法，从而替换您不想测试的任何逻辑。这有助于保持测试实际上只覆盖一个代码单元。

如果您的测试连接到数据库、读取和写入文件、从 Web 服务获取 GET 等，那么它可能真的是一个集成测试。集成测试非常有用，因为您可以检测单元测试无法识别的问题。但是单元测试的好处是，如果一个写得很好的单元测试失败了，你已经知道代码的哪一部分有问题，预期的行为是什么以及发生了什么。

读取输入文件时，文件成为测试的一部分，因此现在您将测试拆分为两个位置。任何想了解测试的人可能需要打开文件并查看它，您需要将文件添加到源代码管理等。如果文件很短，那么最好只模拟 I/O 函数测试在一个地方。

于 2017-03-03T14:25:14.687 回答