大家好我开始学习单元测试或TDD。
我有一些关于C＃的经验，所以我开始使用关注链接
https://msdn.microsoft.com/en-us/library/dd264975.aspx
按照样本，到目前为止一切顺利。
但是当我自己开始第一种方法时，
我有一些问题。
我写了一个名为＆＃34; Log＆＃34;
的方法它将创建一个带时间戳的.txt文件
例如，在我调用Log之后（＆＃34;某些错误＆＃34;）;
它将创建一个文件201510210030.txt
内容是＆＃34; [2015-10-21 00:30:47]有些事情错误＆＃34;
我该如何测试？
我可以阅读日志文件吗？
但每次我更改文件名时，
也许我会改变其他情况下的弃牌位置。
或者我可能会将日志更改为DB或某些记录器服务器（使用IoC）
我该如何测试？连接到DB或记录器服务器？阅读文件？
如果方法失败（DB关闭或文件auth失败balabala），则太多可能。
它不是真的＆＃34;单位＆＃34;够了，所以...我如何测试这样的方法，
或者只是我对Unit Test不了解的一些概念。
非常感谢。
答案 0 :(得分：1)
通过单元测试（与所有事情一样），您需要务实。瞄准100％代码覆盖率基准测试总是很棒，但这通常是不现实的。当您开始将实际数据库或文件系统引入测试时，您已经离开了单元测试的领域并进入了集成测试。集成测试绝对没有错，但重要的是不要混淆两者。
我建议您确保将所有日志记录逻辑放在它自己的独立类中，该类通过依赖注入提供给您正在测试的类（您提到IoC，所以我假设您很熟悉）。一旦你这样做，你就可以将一个模拟的“Logger”传递给你的类，它根本不会触及文件系统。这将确保您正在测试的类将处理实现“Logger”接口的任何内容。
如果你真的要对记录器本身进行单元测试，那么我恐怕不可能。记录器与文件系统（或数据库）紧密耦合，因此您无法对其进行单元测试。你总是可以将所有持久性逻辑提取到另一个类并嘲笑它，但你只是把问题推回去了。在你的应用程序和基础设施之间总会有一面墙，两者紧密相连。重要的是保持处理该交互的类相对简单，并确保它使用集成测试进行测试。