C#单元测试的一个小故事

C#单元测试小故事，或许你不了解或是正在学习C#单元测试，那么这个小故事的内涵正式揭示了C#单元测试的实际意义，那么C#单元测试的意义是什么呢？它能带给我们什么呢？让我们来看看：

有一次，有两个开发者：Pat 和Dale。他们面临着相同的最后期限，而这一天也越来越近了。Pat 每天都在着急地编写代码，写完一个类又写一个类，写完一个函数又接着写另一个函数，还经常不得不停下来做一些调整，使得代码能够通过编译。

Pat 一直保持着这种工作方式，直到最后期限的前一天。而这时已经是演示所有代码的时候了。Pat 运行了最上层的程序，但是一点输出也没有，什么都没有。这时只好用调试器来单步跟踪了。“Hmm，决不可能是这样的”，Pat 想，“此时这个变量绝对不是0 啊”。于是，Pat 只能回过头来看代码，尝试着跟踪一下这个难以琢磨的程序的调用流程。

时间已经越来越晚了，Pat 找到并且纠正了这个bug；但在这个过程中，Pat 又找到了其他好几个bug；如此几次过后，bug 还是存在。而程序输出那边，仍然没有结果。这时，Pat 已经筋疲力尽了，完全搞不清楚为什么会这样，认为这种（没有输出的）行为是毫无道理的。

而于此同时，Dale 并没像Pat 那么快地写代码。Dale 在写一个函数的时候，会附带写一个简短的测试程序来测试这个函数（C#单元测试的使用）。这里没有什么特殊的地方，只是添加了一个简单的测试，来判断函数的功能是否和程序员期望的一致。显然，考虑如何写，然后把测试写出来，是需要占用一定时间的；但是Dale 在未对刚写的函数做出确认之前，是不会接着写新代码的。也就是说，只有等到已知函数都得到确认之后，Dale 才会继续编写下一个函数，然后调用前面的函数等等。

在整个过程中，Dale 几乎不使用调试器（C#单元测试的功劳）；而且对Pat 的模样也有些困惑不解：只见他头埋在两手之间，嘀咕着各种难听的话语，咒骂着计算机，充血的眼球同时盯着好几个调试窗口。

最后期限终于到了，Pat 未能完成任务。而Dale 的代码被集成到整个系统中，并且能够很好地运行。之后，在Dale 的模块中，出现了一个小问题；但是Dale 很快就发现了问题所在，在几分钟之内就解决了问题。

现在，是该总结一下上面这个小故事的时候了：Dale 和Pat 的年纪相当，编码能力相当，智力也差不多。唯一的区别就是Dale 非常相信单元测试；对于每个新写的函数，在其他代码使用这个函数并对它形成依赖之前，都要先做单元测试。