我计划跟踪 5-10 之间的方法和类的圈复杂度。如果我们将其保持在该范围内,编写单元测试会更容易吗?它是否有助于我们编写有效的单元测试,从长远来看是有价值的?
我知道可以在不跟踪圈复杂度的情况下正确编写单元测试。
有什么想法吗?
我计划跟踪 5-10 之间的方法和类的圈复杂度。如果我们将其保持在该范围内,编写单元测试会更容易吗?它是否有助于我们编写有效的单元测试,从长远来看是有价值的?
我知道可以在不跟踪圈复杂度的情况下正确编写单元测试。
有什么想法吗?
是的,因为圈复杂度除了计算函数中的决策数量之外什么也没做。
您拥有的决策越多,您在测试中必须考虑的分支就越多。此外,保持较低的圈复杂度将有助于您构建具有更高可维护性的软件,因为它或多或少会迫使您将功能开发得更加原子。举个例子:
您可以编写一个单元测试来涵盖以下功能及其所有 3 个可能的分支:
foo(a, b, c) {
if (a) {
if (b && c) {
return 1;
}
return 2;
}
return 3;
}
或者你可以像这样拆分它:
foo(a, b, c) {
if (a) {
return foo2(b, c);
}
return 3;
}
foo2(b, c) {
if (b && c) {
return 1;
}
return 2;
}
编写两个单元测试,一个用于功能foo2(b,c)
,如果您为功能编写单元测试,foo(a,b,c)
则不再关心其正确性,foo2(b,c)
因为您已经对其进行了测试。
长话短说:圈复杂度不仅会增加可测试性,还会增加代码的可维护性和可读性以及其他非功能性需求。