使用maven和jenkins，如何测试程序员做了一些测试用例？ [英] Using maven and jenkins, how to test the programmers did some test cases?

问题描述

我正在开发一些项目，我们正在使用Java，Springs，Maven和Jenkins进行CI，但我遇到的问题是一些程序员没有向项目中添加真正的junit测试用例。我希望maven和jenkins在部署到服务器之前运行测试。一些程序员进行了空白测试，因此它开始和停止并将通过测试。

I am working on a number of projects and we are using Java, Springs, Maven and Jenkins for CI but I am running into a issues that some of the programmers are not adding real junit test cases to the projects. I want maven and jenkins to run the test before deploying to the server. Some of the programers made a blank test so it starts and stops and will pass the tests.

有人可以告诉我如何自动执行此检查，以便maven和jenkins可以看看测试是否输出了一些输出。

Can someone please tell me how can I automat this check so maven and jenkins can see if the test put out some output.

推荐答案

我没有找到任何解决这个问题的好方法，除了查看代码。

I have not found any good solution to this issue, other than reviewing the code.

代码覆盖率未能检测到我见过的最糟糕的单元测试

Code coverage fails to detect the worst unit tests I ever saw

查看测试次数，也失败了。查看测试名称，您打赌失败。

Looking at the number of tests, fails there too. Looking at the test names, you bet that fails.

如果您有像Kevin这样的开发人员编写类似的测试，那么您只能通过代码捕获这些测试审查。

If you have developers like the "Kevin" who writes tests like those, you'll only catch those tests by code review.

凯文如何击败支票的摘要：

The summary of how "Kevin" defeats the checks:

• 编写一个名为的测试抽烟。在此测试中，您使用不同的参数组合调用所测试类的每个方法，每个调用都包含在 try {...} catch（Throwable t）{/ * ignore * /} 。这为您提供了极好的覆盖范围，测试永远不会失败

• Write a test called smokes. In this test you invoke every method of the class under test with differing combinations of parameters, each call wrapped in try { ... } catch (Throwable t) {/* ignore */}. This gives you great coverage, and the test never fails

写一堆空测试，其名称听起来像是您想过的花哨的测试场景，例如 widgetsTurnRedWhenFlangeIsOff ， widgetsCounterrotateIfFangeGreaterThan50 。这些都是空的测试，所以永远不会失败，经理检查CI系统会看到很多详细的测试用例。

Write a load of empty tests with names that sound like you have thought up fancy test scenarios, eg widgetsTurnRedWhenFlangeIsOff, widgetsCounterrotateIfFangeGreaterThan50. These are empty tests, so will never fail, and a manager inspection the CI system will see lots of detailed test cases.

代码审查是捕获凯文的唯一方法。

Code review is the only way to catch "Kevin".

希望你的开发人员不那么糟糕

Hope your developers are not that bad

今天早上我有一个淋浴时刻。有一种类型的自动分析可以捕获凯文，不幸的是它仍然可以被欺骗，所以虽然它不是人们编写错误测试的解决方案，但它确实使编写糟糕的测试变得更加困难。

I had a shower moment this morning. There is a type of automated analysis that can catch "Kevin", unfortunately it can still be cheated around, so while it is not a solution to people writing bad tests, it does make it harder to write bad tests.

变异测试

这是一个旧项目，不适用于最近的代码，我不建议你使用它。但我建议它暗示一种自动分析会停止凯文

This is an old project, and won't work on recent code, and I am not suggesting you use this. But I am suggesting that it hints at a type of automated analysis that would stop "Kevin"

如果我实现这个，我会做的是写一个JestingClassLoader例如，使用ASM，一次用一个小jest重写字节码。然后在加载此类加载器时针对您的类运行测试套件。如果测试没有失败，你就在凯文的土地上。问题是您需要针对代码中的每个分支点运行所有测试。但是，您可以使用自动覆盖率分析和测试时间分析来加快速度。换句话说，您知道每个测试执行的代码路径，因此当您针对某个特定路径进行jest时，您只运行命中该路径的测试，并从最快的测试开始。如果这些测试都没有失败，你就会发现测试覆盖率存在缺陷。

If I were implementing this, what I would do is write a "JestingClassLoader" that uses, e.g. ASM, to rewrite the bytecode with one little "jest" at a time. Then run the test suite against your classes when loaded with this classloader. If the tests don't fail, you are in "Kevin" land. The issue is that you need to run all the tests against every branch point in your code. You could use automatic coverage analysis and test time profiling to speed things up, though. In other words, you know what code paths each test executes, so when you make a "jest" against one specific path, you only run the tests that hit that path, and you start with the fastest test. If none of those tests fail, you have found a weakness in your test coverage.

所以如果有人要让Jester现代化，你就有办法找到凯文出局。

So if somebody were to "modernize" Jester, you'd have a way to find "Kevin" out.

但这并不能阻止人们写错考试。因为您可以通过编写测试来传递该检查，该测试验证代码的行为与目前的行为，错误和所有行为。哎呀甚至有销售软件的公司会为你编写测试。我不会通过链接到这里给他们谷歌网页排名，但我的观点是，如果他们得到这样的软件，你将有大量的测试，直接夹克你的代码库，并没有发现任何错误（因为作为当您更改任何内容时，生成测试将失败，因此现在进行更改需要争论更改本身以及更改破坏的所有单元测试的更改，从而增加业务成本以进行更改，即使该更改正在修复真正的错误）

But that will not stop people writing bad tests. Because you can pass that check by writing tests that verify the code behaves as it currently behaves, bugs and all. Heck there are even companies selling software that will "write the tests for you". I will not give them the Google Page Rank by linking to them from here, but my point is if they get their hands on such software you will have loads of tests that straight-jacket your codebase and don't find any bugs (because as soon as you change anything the "generated" tests will fail, so now making a change requires arguing over the change itself as well as the changes to all the unit tests that the change broke, increasing the business cost to make a change, even if that change is fixing a real bug)

这篇关于使用maven和jenkins，如何测试程序员做了一些测试用例？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！