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

开发 后端
C#单元测试是什么呢?这里我们不是要向你介绍一个简单的例子,而是从一个故事入手向你介绍C#单元测试的作用、存在的意义是什么?希望对你理解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 非常相信单元测试;对于每个新写的函数,在其他代码使用这个函数并对它形成依赖之前,都要先做单元测试。

而Pat 则没有这么做,他总是“知道”代码的行为应该和所期望的完全一样,并且等到所有代码都差不多写完的时候,才想起来运行一下代码。然而到了这个时候,要想定位bug,或者,甚至是确定哪些代码的行为是正确的,哪些代码的行为是错误的,都为时已晚了。

C#单元测试的小故事就向你介绍到这里,那么通过这两个程序员的开发过程,大致的关于C#单元测试的理解是不是对你有点帮助呢?

【编辑推荐】

  1. C#创建Excel文件实例讲解
  2. 浅析C#创建Excel文件实现的实际操作
  3. C#多态性的理解详谈
  4. C#多态性概念及特点的解析
  5. C#取整函数实例应用详解
责任编辑:仲衡 来源: 博客园
点赞
收藏

51CTO技术栈公众号