3 回答
TA贡献1982条经验 获得超2个赞
您需要重构您的代码并使其更适合测试。
这是我会怎么做:
func openAndReadFile(fileName string) [][]string {
file, err := os.Open(fileName)
if err != nil {
fmt.Printf("Failed to open file: %s", fileName)
}
lines, err := readFile(file)
if err != nil {
fmt.Printf("Failed to read file: %s", fileName)
}
return lines
}
func readFile(reader io.Reader) ([][]string, error) {
r := csv.NewReader(reader)
lines, err := r.ReadAll()
if err != nil {
log.Fatal(err)
}
return lines, err
}
然后为了测试,您可以简单地使用实现该io.reader接口的任何数据结构。例如,我使用字节缓冲区,但您可以选择网络连接:
func TestReadFile(t *testing.T) {
var buffer bytes.Buffer
buffer.WriteString("fake, csv, data")
content, err := readFile(&buffer)
if err != nil {
t.Error("Failed to read csv data")
}
fmt.Print(content)
}
TA贡献2041条经验 获得超4个赞
您显示的功能主要由交互决定:与文件系统的交互以及与 csv 阅读器的交互。为确保这些交互工作良好,您以后无论如何都必须针对文件系统和 csv 阅读器进行一些集成测试。想想你希望找到哪些错误,你会发现错误更可能出现在交互层面:文件的顺序是正确的,还是应该相反?nil 真的是表示没有错误的值吗?您是否必须为 Open 提供更多论据?ETC。
因此,我不会专注于对该功能进行单元测试。然而,这个函数是一个很好的候选者,可以模拟它使周围代码的单元测试更容易。因此,模拟openAndReadFile
对周围代码进行单元测试,并openAndReadFile
使用集成测试进行测试。
TA贡献1966条经验 获得超4个赞
我强烈建议使用接口而不是文件名字符串,就像这里推荐的其他答案一样,但如果你真的必须这样做,唯一的方法可能是使用临时文件。使用字符串文件名的决定已将代码锁定为假设文件系统上存在某些内容,并推入了文件管理的责任。
- 3 回答
- 0 关注
- 168 浏览
添加回答
举报