代码覆盖率无法检测到我见过的最糟糕的单元测试
如果您拥有像“ Kevin”这样的开发人员来编写此类测试,则只能通过代码审查来捕获这些测试。
“ Kevin”如何击败检查的摘要:
编写一个名为的测试smokes
。在此测试中,您将使用不同的参数组合调用被测类的每个方法,每个调用都包装在中try { ... } catch (Throwable t) {/* ignore */}
。这为您提供了广泛的覆盖范围,并且测试从未失败
编写空测试用的名字听起来像你已经想到了花哨的测试场景,例如负载widgetsTurnRedWhenFlangeIsOff
,widgetsCounterrotateIfFangeGreaterThan50
。这些是空的测试,因此将永远不会失败,并且经理检查CI系统将看到许多详细的测试用例。
希望您的开发人员没有那么糟糕
今天早上我洗个澡。有一种自动分析可以捕获“ Kevin”,但是不幸的是它仍然可以被欺骗,因此尽管它不是编写不良测试的解决方案,但确实使编写不良测试变得更加困难。
这是一个旧项目,无法在最新代码上使用,我不建议您使用此代码。但是我建议它暗示一种自动分析类型,它将阻止“ Kevin”
如果要实现这一点,我将要做的是编写一个“ JestingClassLoader”,它使用例如ASM一次用一个小的“笑话”来重写字节码。然后,在使用该类加载器加载后,针对您的类运行测试套件。如果测试没有失败,那么您就在“凯文”地区。问题是您需要针对代码中的每个分支点运行所有测试。不过,您可以使用自动覆盖率分析和测试时间分析来加快速度。换句话说,您知道每个测试执行的代码路径,因此,当对一个特定路径进行“开玩笑”时,您仅运行符合该路径的测试,然后从最快的测试开始。如果这些测试都没有失败,则说明您的测试覆盖范围很弱。
因此,如果有人要对“弄臣”进行“现代化”,那么您将有办法找出“凯文”。
但这不会阻止人们编写不良测试。因为您可以通过编写测试来通过该检查,以验证代码的行为是否符合当前的行为,错误以及所有。哎呀,甚至有一些公司出售会“为您编写测试”的软件。我不会通过从此处链接到他们来为他们提供Google Page排名,但是我的观点是,如果他们能够使用此类软件,您将拥有大量测试,这些测试会直接影响您的代码库,并且不会发现任何错误(因为更改任何内容后,“生成的”测试将立即失败,因此,进行更改需要争论更改本身以及更改所导致的所有单元测试的更改,即使更改,业务成本也会增加该更改正在修复一个真正的 错误)