单元测试入门

好吧,这里有一些来自一些没有尽可能多地进行单元测试的人的最佳实践。..咳嗽。

1. 确保你的测试测试 one 只有一件事。
2. 边写单元测试。更可取地 before 你编写你正在测试的代码。
3. 不要对GUI进行单元测试。
4. Separate your concerns .
5. 尽量减少测试的依赖性。
6. 模仿behviour mocks .

你可能想看看 TDD on Three Index Cards 和 Three Index Cards to Easily Remember the Essence of Test-Driven Development :

卡片#1。伯伯三定律

• 除非通过失败的测试,否则不要编写生产代码。
• 只写足够的测试来证明失败。
• 只编写足够的生产代码以通过测试。

卡片#2:第一原则

• 快:令人麻木的快,如每秒数百或数千次。
• 隔离:测试清楚地隔离了故障。
• 可重复:我可以反复运行它,每次都会以相同的方式通过或失败。
• 自我验证:测试明确通过失败。
• 及时:与微小的代码更改同步生产。

卡片#3:TDD的核心

• 红色:测试失败
• 绿色:测试通过
• 重构:干净的代码和测试

所谓 xUnit 框架被广泛使用。它最初是作为SUnit为Smalltalk开发的,后来演变为JUnitforJava,现在有许多其他实现,如NUnitforJava。网。这几乎是一个事实上的标准——如果你说你在使用单元测试,大多数其他开发人员会认为你的意思是xUnit或类似的。

“最佳实践”的一个很好的资源是 Google Testing Blog 例如,最近的一篇帖子 Writing Testable Code 是一种极好的资源。具体来说,他们的“厕所测试”系列每周帖子非常适合在你的立方体或厕所周围发布,所以你可以随时考虑测试。

xUnit系列是单元测试的核心。它们被集成到Netbeans、Eclipse和许多其他IDE中。它们为单元测试提供了一种简单、结构化的解决方案。

在编写测试时,我总是尝试做的一件事是尽量减少外部代码的使用。我的意思是:我尽量减少测试的设置和拆卸代码,并尽量避免使用其他模块/代码块。编写良好的模块化代码在安装和拆卸过程中不应该需要太多的外部代码。

NUnit是一个很好的工具。NET语言。

单元测试可以通过多种方式使用:

1. 测试逻辑
2. 增加代码单元的分隔。如果你不能完全测试一个函数或一段代码,那么组成它的部分就太相互依赖了。
3. 推动开发,有些人编写测试 之前 他们编写要测试的代码。这迫使你思考你想要代码做什么 做 ,然后给你一个明确的指导方针,告诉你什么时候实现了这一目标。

别忘了重构支持。重新锐化。NET为缺失的代码提供了自动重构和快速修复。这意味着,如果你写一个对不存在的东西的调用,ReSharper会问你是否想创建缺失的部分。