如果单元测试方法的圈复杂度为1，如果它们是较大交互作用的一部分，我应该测试它吗？

我对单元测试很陌生，所以请原谅一个天真的问题。如果单元测试方法的圈复杂度为1，如果它们是较大交互作用的一部分，我应该测试它吗？

我听说过没有测试具有1的圈复杂度的任何东西的想法。这对我很有趣b/c我在事件之间做了很多交互测试。例如，按下按钮，触发事件，在演示者上引发事件，演示者修改模型，演示者在视图上调用方法。所以我测试以确保当按钮事件发生时，调用视图上正确的方法。

此序列中的每种方法的环复杂度为1.没有分支。但如果我想测试它作为一个“系统”（即视图，演示者，模型），圈复杂度更高 - 将事件序列中的所有1值方法相加。

所以我的问题是，当人们建议我不需要测试具有1的圈复杂度的方法时，他们是不是在讨论用于测试类之间交互的交互测试，就像我上面所描述的那样？

我本周两次遇到这个想法 - 一次在Mark Seemann Pluralsight视频中，一次在这里：http://webquali.com/blog/67/15-ways-to-write-beautiful-code.html。

来源

2017-03-26 Trevor

虽然它可能是有趣的讨论，我不认为它适合SO格式。 – Lanorkin

这是比较教条式的（因为它主要是基于观点的，所以对于StackOverflow而言是偏离主题的）。也就是说，如果您无法看到针对方法本身的测试值，那么通常表示a）集成测试更有用的区域，或者b）您应该对堆栈中的一个或两个方法进行“单元测试”如果可以在没有外部依赖的情况下进行完全封装，则不会成为真正的集成测试。 –

至于问题考虑例如有1作为圈复杂度的方法'int Multiply（int a，int b）{return a - b; }' - 这显然是错误的 - 为什么你不测试它？我认为你不应该从“现在它是简单的方法 - 我不会测试它”，而是从“我应该测试方法合同无论如何不管它有什么身体” – Lanorkin

考虑的不是规定性TDD方面的测试，而是作为一种线索，使您的开发人员能够确定CI在运行集成时是否会发生意外的行为变化。

举一个简单的例子，你在评论中规定，一个计算器方法：

public int Minus(int a, int b) => a - b;

不编写单元测试可能会导致有人不小心改变，像这样的代码：

public int Minus(int a, int b) => a + b;

这将不可避免地破坏整个应用程序在运行时。

因此，建议通常是：对于团队中开发人员编写的每行代码，有人编写代码时，应该有相应的隐式或显式断言。

当我们说隐式断言，我们的意思是，例如：

public object ReturnMytype() => new MyType { MyProperty = "a" };

[TestMethod] 
public void ReturnMytype_SetsMyPropertytoA(){ 
    Assert.AreEqual("a", (new MyClass().ReturnMytype as MyType).MyProperty); 
}

在上述单元测试断言ReturnMytype返回正确的类型是隐式的（类型转换）。这一个测试足以证明被测方法的两种行为 - 它返回一个MyType，并且它将MyProperty设置为“a”。

来源

2017-03-26 13:23:55 zaitsman

如果单元测试方法的圈复杂度为1，如果它们是较大交互作用的一部分，我应该测试它吗？

回答

相关问题