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