单元测试
测试还应具备哪些其他特性?
答案 0 :(得分:7)
阿。我最喜欢的科目:-)从哪里开始...
根据Gerard Meszaros的xUnit测试模式(关于单元测试的书)
使这更容易的一些事情:
其他要注意的事项:
<强>命名强>
有一个描述性的名称。测试名称应该与规范一样。如果你的名字太长,你可能会测试太多。
<强>结构强>
使用AAA结构。这是模拟框架的新时尚,但我认为这是构建所有测试的好方法。
安排你的背景 行动,做需要测试的事情 断言,断言要检查的内容
我通常将测试划分为三个代码块。了解这种模式可以使测试更具可读性。
Mocks vs. Stubs
使用模拟框架时,总是尝试使用存根和基于状态的测试,然后再进行模拟。
Stubs是代表您尝试测试的对象的依赖项的对象。您可以将行为编程到它们中,并且可以在测试中调用它们。 Mocks通过让你断言是否被调用以及如何调用来扩展它。模拟是非常强大的,但它允许您测试实现而不是代码的前后条件。这往往会使测试更加脆弱。
答案 1 :(得分:3)
实用程序员的回答:好的测试应该是A-TRIP
答案 2 :(得分:1)
答案 3 :(得分:1)
答案 4 :(得分:1)
我还没有看到其他人提到的是小。单元测试应该测试一个特定的东西,这就是全部。我试图通过将它们重构为自己的方法来实现只有一个断言并最小化设置代码的数量。我还将创建自己的自定义断言。一个不错的小单元测试IMO约10行或更少。当测试很小时,很容易快速了解测试尝试做什么。从长远来看,大型测试最终无法维持。
当然,小小并不是我唯一的目标...它只是我在单元测试中所重视的事情之一。 : - )
答案 5 :(得分:0)
要记住的其他因素是运行时间。如果测试运行时间太长,可能会跳过。
答案 6 :(得分:0)
答案 7 :(得分:0)
单元测试应该很快:数百次测试应该能够在几秒钟内完成。
答案 8 :(得分:0)
如果出现以下情况,则测试不是单元测试:
做这些事情的测试也不错。通常它们值得写作,它们可以用单元测试工具编写。但是,能够将它们与真正的单元测试分开是很重要的,这样我们就可以保留一组测试,每当我们进行更改时,我们都可以快速运行这些测试。