python—在unitest中执行I/O是一种不好的做法吗

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

_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不是一个好的实践，是真的吗

但是有人告诉我在unitest中进行I/O不是一个好的实践，是真的吗

我认为在单元测试中执行I/O并不一定不好

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

---

另外，你有没有试着问那些给你这个建议的人，他们提出这个建议的具体原因是什么？

一般来说，最好的做法是编写测试，这样只有当预期的行为没有产生时，测试才会失败

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

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

---

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

嗯，这不是不可原谅的，但我想说你确实需要一个很好的理由。你为什么要把整个I/O机器拉进来，让你的测试依赖于非源文件的位置和内容？如果你从来都不应该在测试中做I/O，那么做日志记录是相当困难的。我会回音@delnan，说这真的取决于你使用I/O的用途。