开始单元测试

好吧,这里是一些最好的实践,来自于一个没有尽可能多的单元测试的人……咳嗽。

1. 确保你的测试 one 只有一件事。
2. 随时随地编写单元测试。更可取地 before 编写测试代码。
3. 不要对GUI进行单元测试。
4. Separate your concerns .
5. 最小化测试的依赖性。
6. 用…来模仿观看者 mocks .

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

卡1。伯伯伯三定律

• 除了通过一个失败的测试外,不要编写任何生产代码。
• 只写足够的测试来证明失败。
• 只写足够的生产代码来通过测试。

卡2:第一原则

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

卡3:TDD的核心

• 红色:测试失败
• 绿色:测试通过
• 重构:清除代码和测试

所谓 xUnit 框架被广泛使用。它最初是以SUnit作为SUnit开发的,演变成Java的JUnit,现在有许多其他的实现,如NUnit for .NET。这几乎是一个事实上的标准——如果你说你在使用单元测试,大多数其他开发人员会认为你是指XUnit或类似的东西。

“最佳实践”的一个重要资源是 Google Testing Blog ,例如最近在 Writing Testable Code 是一种极好的资源。特别是他们的“厕所测试”系列每周贴子非常适合在你的立方体或厕所周围张贴,所以你可以一直考虑测试。

Xunit家族是单元测试的中流砥柱。它们集成在NetBeans、Eclipse和许多其他IDE中。它们为单元测试提供了一个简单、结构化的解决方案。

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

对于任何一种.NET语言来说,nunit都是一个很好的工具。

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

1. 测试逻辑
2. 增加代码单元的分隔。如果您不能完全测试一个函数或一段代码,那么组成它的部分就太多了。
3. 驱动开发,有些人编写测试 之前 他们编写要测试的代码。这迫使您考虑代码的用途 做 然后给你一个明确的指导方针,当你已经实现了。

不要忘记重构支持。.NET上的Resharper为缺少的代码提供自动重构和快速修复。这意味着如果你给不存在的东西写了一个调用,resharper会问你是否想创建丢失的部分。