【发布时间】:2013-09-25 11:43:42
【问题描述】:
我是单元测试的新手,并且已经阅读了好几遍我们应该先编写单元测试然后再编写实际代码。到目前为止,我正在编写我的方法,然后对代码进行单元测试。
如果您先编写测试...
您倾向于编写代码以适应测试。这鼓励了 “解决问题的最简单的事情”类型的开发和保持 你专注于解决问题而不是解决元问题。
如果你先写代码……
您会很想编写适合代码的测试。实际上这 相当于编写问题以适合您的答案,即 有点倒退,并且经常会导致测试 价值较低。
对我来说听起来不错。但是,即使在我的代码到位之前,我如何编写单元测试? 我是按字面意思接受建议吗?这是否意味着我应该准备好我的 POCO 类和接口,然后编写单元测试?
谁能用一个简单的例子来解释我是如何做到的,比如两个数字相加?
【问题讨论】:
-
编写测试首先会迫使您考虑一个类/方法/算法应该在真正实现它之前做什么。这就像说“这是我想要发生的事情!我会担心以后的如何。”
-
要考虑的一件事是,当您已经有了针对特定组件的设计时,TDD 是很好的选择。这通常发生在原型之后。如果您正在设计原型或进行 RAD,TDD 将成为障碍。
-
@lazyberezovsky 很好的例子。谢谢。
-
我强烈建议,一旦你掌握了它的基础知识,我的意思是可能需要一周的练习,你就可以查看 Visual Studio 的 NCrunch add-on。 Mono 也有另一种选择,但它会在您编写测试时在后台运行您的测试。试试这个演示,我想你会被迷住的。我与他们没有任何关系,但没有它我永远不会编码。
标签: c# unit-testing nunit moq