在单元测试中进行I / O是不好的做法

时间:2012-05-30 18:09:33

标签: python unit-testing

我有一些单元测试正在做类似的事情:

_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)
}

但有些人告诉我,在单元测试中进行I / O并不是一个好习惯,这是真的吗?

2 个答案:

答案 0 :(得分:7)

  

但是有些人告诉我,在unitest中进行I / O并不是一个好习惯,这是真的吗?

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

唯一需要注意的是,如果您的单元测试依赖于某些预先存在的数据文件来执行其操作,那么这些文件应被视为单元测试的一部分(因此受版本控制等)。

P.S。您是否尝试过询问那些根据建议背后的具体原因向您提供此建议的人?

答案 1 :(得分:0)

一般而言,最佳做法是编写测试,以便仅在未生成预期行为时才会失败。

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

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

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