单元测试原理
本文关键字：单元测试 | 更新日期: 2023-09-27 18:18:28
大家好，我开始学习单元测试或TDD。
我有一些c#的经验，所以我从follow link
开始https://msdn.microsoft.com/en-us/library/dd264975.aspx按照样例，到目前为止一切顺利。
但是当我自己开始第一个方法时，
我有一些问题。我写了一个名为"Log"的方法
它将创建一个时间戳为 的。txt文件。例如，在我调用Log("some thing error")之后;它将创建一个文件201510210030.txt
内容为"[2015-10-21 00:30:47]some thing error"
我如何测试它?
我可以读日志文件吗?
但是每次我更改文件名，
也许我会在其他情况下改变折叠位置。
或者我可能会将日志更改为DB或一些日志服务器(带有IoC)
我如何测试它?连接到数据库或日志服务器?读取文件?
如果方法失败(DB关闭或文件验证失败balabala)太可能。
不够"单位"，所以…如何测试这样的方法，
或者只是一些我不理解单元测试的概念。
非常感谢。
对于单元测试(和所有事情一样)，您需要务实。以100%的代码覆盖率为基准总是很棒的，但这通常是不现实的。一旦您开始在测试中引入实际的数据库或文件系统，您就离开了单元测试的领域，进入了集成测试的领域。集成测试绝对没有错，但重要的是不要混淆这两者。
我的建议是确保所有的日志逻辑都在它自己的独立类中，通过依赖注入提供给你正在测试的类(你提到了IoC，所以我假设你很熟悉)。这样做之后，就可以在类中传入一个模拟的"Logger"，它根本不涉及文件系统。这将确保您正在测试的类将处理实现该"Logger"接口的任何内容。
如果你想对记录器本身进行单元测试，那么恐怕这是不可能的。日志记录器与文件系统(或数据库)紧密耦合，因此无法对其进行单元测试。您总是可以将所有持久性逻辑提取到另一个类中并模拟出来，但您只是将问题推回了过去。在应用程序和基础设施之间总是会遇到一堵墙，这两者是紧密耦合的。重要的是保持处理交互的类相对简单，并确保用集成测试对其进行了测试。