单元测试原理

Question

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

我对C＃的一些经验，所以我与后续环节

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

按照样品开始，到目前为止，一切顺利。

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

我有一些问题。

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

它会创建一个时间戳

例如.txt文件，我叫日志（“一些事错误”）之后;

它会创建一个文件201510210030.txt

的内容为“[2015年10月21日0时30分四十七秒]一些事错误”

如何测试呢？

我可以读取日志文件吗？

但每次我更改文件名时，

也许我会改变对其他情况的褶皱现在的位置。

或者，也许我会改变日志，数据库或一些记录服务器（国际奥委会）

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

如果该方法失败（数据库关闭或文件身份验证失败balabala），则可能性过大。

它不是真正的“单位”够了，所以...我怎么测试这样的方法，

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

非常感谢。

Answer 1

随着单元测试（与所有的东西一样），你需要务实。瞄准100％代码覆盖率基准总是很好的，但这往往是不切实际的。在您开始将实际数据库或文件系统引入到测试中的那一刻，您已经离开了单元测试领域并进入了集成测试。集成测试绝对没有错，但重要的是不要混淆两者。

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

如果你正在寻找实际单元测试记录仪本身，那么恐怕这是不可能的。记录器与文件系统（或数据库）紧密耦合，因此您无法真正进行单元测试。你总是可以把所有的持久化逻辑提取到另一个类中，然后模拟出来，但是你只能把问题推回去。在应用程序和基础架构之间总会有一堵墙，在两者紧密结合的地方。重要的是让处理这种交互的类相对简单，并确保它使用集成测试进行测试。