TDD:断言的数量,以及实际断言的内容？

Question

我目前正在使用TDD编写测试,我遇到了一些问题.

通常在编写单元测试时,我总是习惯于每单元测试使用1个断言,因为这被定义为良好实践,并且很容易理解为什么测试失败.

在TDD中,做同样的事情也是一种好习惯,如果是这种情况,那么使用TDD有效地设计1个方法我将最终得到超过1个单元测试 - 因为我实际上需要超过1个断言.

另一个问题是我实际上断言了什么？

我可以断言我认为返回对象可能是什么？

所以我必须创建返回类型(可能是复杂的许多属性)并确保这些在断言上匹配,这在技术上可能是1断言.

或者另一种方式是确保我沿途弥补的嘲讽实际上被调用,即我的MOQ我可以做以下

     myServiceMock.Verify(x => x.ItemsReceived(), Times.Once());

所以我可以确保在我的模拟上只调用一个方法,这实际上被归类为断言.所以它回到原始查询,每单元测试1断言,所以我需要创建额外的单元测试,以确保调用其他模拟上的其他方法.

其他人在这做什么？

你是断言在mocks上调用方法还是按照你的期望返回值.

真的很期待任何人对此有任何意见.

Answer 1

我看到你的问题有不同的问题,我想介绍一下.

首先,关于每次测试的一个断言.如果这是好的做法,那就有不同的想法.事实是,严格遵守它会使事情变得过于复杂.TDD应该帮助您设计良好和干净的代码,但不能让您严格遵守某些原则.您可以在此处阅读Robert Martin的简洁代码中的此主题.

其次,是否要使用模拟框架查看对象内部发生的事情,或者只是断言某些值取决于您正在编写的测试类型.

您可以在验证状态的测试或验证行为的测试中对测试进行分类.

• 对于基于状态的测试,您将检查与测试相关的某些值,例如,如果我的add函数返回了正确的值.
• 对于基于行为的测试,您可以使用模拟对象来验证行为,因为通过生产代码验证结果通常并不容易,例如,考虑如何自动验证直接输出到调制解调器或监视器等设备的数据.

查看Martin Fowler 关于此主题的优秀文章Mocks Are Not Stubs.

第三,说实话,我并不完全确定你的意思是:

在TDD中,做同样的事情也是一种好习惯,如果是这种情况,那么使用TDD有效地设计1个方法我将最终得到超过1个单元测试 - 因为我实际上需要超过1个断言.

我假设你认为你只需要编写一个你想要实现的新方法的单一测试,这将是疯狂的.试想实现除法函数.你如何确保除法正常工作,并且在除以0的情况下产生错误？这是不可能的.这意味着您至少需要为此方法进行两次测试.

第四,测试驱动开发中的"测试"是一个非常有偏见的术语.一般来说,人们倾向于认为在TDD中你定义测试以确保你的代码没有被破坏,这通常是测试人员而不是开发人员的任务.但是,在TDD中,您应该考虑单元测试是为尚未实现的方法或类定义行为.

差异似乎微不足道,但它是一个非常有力的声明.它可以让您在实际编写单行代码之前告诉程序您期望的是什么.想一想,让它沉入其中并尝试一下.它制造了巨大的差异.BDD是出于这种想法而创建的.但是,还有更多.您可以通过这个优秀的演示文稿从它的发明者Dan North获得有关BDD的更多细节.

所有这些不仅是我对事物的看法,也是伟大的软件开发人员的观点.所以,我希望它能让你对TDD有一个很好的看法,并帮助你继续你的旅程,

Answer 2

对于所有编写测试的人来说,这是一个常见问题.

在我看来(我知道还有很多其他的)一个断言每测试教条(1A/T)对基本单元测试有效,比如1 + 1 = 2.随着整个应用程序规模的增加,例如在集成或系统测试中,这将不再起作用.但那可能不是你的范围.

给问题一个面子:

[TestMethod]
public void TwoAsserts()
{
    int a = 42;
    int b = 17;

    int quotient;
    int remainder;

    quotient = Math.DivRem(a, b, out remainder);

    Assert.AreEqual(2, quotient, "quotient is wrong");
    Assert.AreEqual(8, remainder, "remainder is wrong");
}

这两个断言的替代方案是什么？

使用相同的输入但不同的断言进行两次测试？当然不是.

编写一个专门的断言方法(就像你提到的那样)检查所有输出并在之后失败？也许.

但是你应该记住,测试应该易于理解和维护.阅读测试的每个人 - 包括初学者或不是技术人员 - 都应该清楚地看到你要测试的内容以及你的输入,输出和断言是什么.

"代码读取的次数比写入的频率高得多"(测试也是如此)

此外,当商断言失败时,谁在乎你是否有剩余的传递？这是否意味着你通过了50%？不,在质量方面,这将是100%错误.因此,请继续修复您的软件并再次运行测试.绿色？好!

总结:保持测试简单并尽可能少地使用断言,但需要尽可能多的断言.阻止你编写测试的一切都是邪恶的.