单元测试原理

Question

大家好，我开始学习单元测试或 TDD。

我在 C# 方面有一些经验，所以我从以下链接开始

https://msdn.microsoft.com/en-us/library/dd264975.aspx

遵循示例，到目前为止一切顺利。

但是当我自己开始第一种方法时，

我有一些问题。

我写了一个名为“Log”的方法

它将创建一个带有时间戳的 .txt 文件

例如，在我调用 Log("something error");

它将创建一个文件 201510210030.txt

内容是“[2015-10-21 00:30:47] 某事出错”

如何测试它？

我可以阅读日志文件吗？

但是每次改文件名，

也许我会在其他情况下更改折叠位置。

或者我可能会将日志更改为 DB 或某些记录器服务器（使用 IoC）

如何测试它？连接到数据库或记录器服务器？读取文件？

如果方法失败（数据库关闭或文件验证失败balabala）的可能性太大。

它还不够“单元”，所以......我该如何测试这样的方法，

或者只是一些我不理解单元测试的概念。

非常感谢。

Answer 1

对于单元测试（与所有事物一样），您需要务实。以 100% 的代码覆盖率基准为目标总是很棒，但这通常是不切实际的。当您开始在测试中引入实际的数据库或文件系统时，您就已经离开了单元测试的领域并进入了集成测试。集成测试绝对没有错，但重要的是不要混淆两者。

我的建议是确保您在它自己的单独类中拥有所有日志记录逻辑，该类通过依赖注入提供给您正在测试的类（您提到了 IoC，所以我假设您很熟悉）。一旦你这样做了，你就可以将一个模拟的“记录器”传递到你的类中，它根本不接触文件系统。这将确保您正在测试的类将处理实现该“记录器”接口的任何内容。

如果您希望对记录器本身进行实际单元测试，那么恐怕这不太可能。记录器与文件系统（或数据库）紧密耦合，因此您无法真正对其进行单元测试。您总是可以将所有持久性逻辑提取到另一个类并对其进行模拟，但您只是将问题推回。在您的应用程序和基础架构之间总会遇到一堵墙，而这两者是紧密耦合的。重要的是保持处理该交互的类相对简单，并确保使用集成测试对其进行测试。