单元测试入门

Question

  

粗略地说，单元测试是用测试代码单独测试代码的一部分。想到的直接好处是：

     

  
• 运行测试变得可自动化且可重复
  
• 您可以通过GUI
进行比点击式测试更精细的测试   

     

Rytmis

我的问题是，目前工具方面的“最佳做法”是什么，以及何时何地使用单元测试作为日常编码的一部分？

让我们尝试在某种程度上与语言无关并覆盖所有基础。

Answer 1

好的，这是一些最佳实践，来自一个没有按照他应该进行单元测试的人......咳嗽。

1. 确保您的测试测试one 只有一件事。
2. 随时编写单元测试。最好before编写您正在测试的代码。
3. 不要对GUI进行单元测试。
4. Separate your concerns。
5. 最大限度地减少测试的依赖性。
6. 用mocks模仿行为。

Answer 2

您可能需要查看TDD on Three Index Cards和Three Index Cards to Easily Remember the Essence of Test-Driven Development：

卡＃1。鲍勃叔叔的三条法则

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

卡片＃2：第一原则

• 快速：心灵快速，如每秒数百或数千。
• 隔离：测试清楚地隔离了一个错误。
• 可重复：我可以重复运行它，每次都会以相同的方式通过或失败。
• 自我验证：测试明确地通过 - 失败。
• 及时：与微小的代码更改保持同步。

卡＃3：TDD的核心

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

Answer 3

所谓的xUnit框架被广泛使用。它最初是为Smalltalk开发的，作为SUnit，演变成JUnit for Java，现在有许多其他实现，如NUnit for .Net。它几乎是事实上的标准 - 如果你说你正在使用单元测试，大多数其他开发人员会认为你的意思是xUnit或类似的。

Answer 4

“最佳做法”的重要资源是Google Testing Blog，例如Writing Testable Code上的最新帖子是一个很棒的资源。特别是他们的“厕所测试”系列每周帖子非常适合在您的立方体或厕所周围张贴，因此您可以随时考虑测试。

Answer 5

xUnit系列是单元测试的中流砥柱。它们集成在Netbeans，Eclipse和许多其他IDE中。它们为单元测试提供了简单，结构化的解决方案。

在编写测试时我总是尝试做的一件事是尽量减少外部代码的使用。我的意思是：我尽可能地尽量减少测试的设置和拆卸代码，尽量避免使用其他模块/代码块。编写良好的模块化代码在设置和拆卸时不需要太多外部代码。

Answer 6

NUnit是适用于任何.NET语言的好工具。

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

1. 测试逻辑
2. 增加代码单元的分离。如果你无法完全测试一个函数或一段代码，那么构成它的部分就会相互依赖。
3. 驱动开发，有些人在之前编写测试他们编写要测试的代码。这会迫使你思考你希望代码做什么，然后给你一个关于你何时实现它的明确指导。

Answer 7

不要忘记重构支持。 ReSharper on .NET为丢失的代码提供自动重构和快速修复。这意味着如果你打电话给不存在的东西，ReSharper会询问你是否要创建缺失的部分。