使用maven和jenkins，如何测试程序员做了一些测试用例？

Question

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.

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

Answer 1

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.

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:

• 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

• 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

Update

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.

Mutation Testing

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"

If I were implementing this, what I would do is write a "JestingClassLoader" that uses, eg 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.

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)

Answer 2

I would recommend using Sonar which has a very useful build breaker plugin.

Within the Sonar quality profile you can set alerts on any combination of metrics , so, for example you could mandate that your java projects should have

• "Unit tests" > 1
• "Coverage" > 20

Forcing developers to have at least 1 unit test that covers a minimum of 20% of their codebase. (Pretty low quality bar, but I suppose that's your point!)

Setting up an additional server may appear like extra work, but the solution scales when you have multiple Maven projects. The Jenkins plugin for Sonar is all you'll need to configure. Jacoco is the default code coverage tool, and Sonar will also automatically run other tools like Checkstyle, PMD and Findbugs.

Finally Stephen is completely correct about code review. Sonar has some basic, but useful, code review features.

Answer 3

You need to add a code coverage plugin such as JaCoCo, EMMA, Cobertura, or the likes. Then you need to define in the plugin's configuration the percent of code coverage (basically "code covered by the tests") that you would like to have, in order for the build to pass. If it's below that number, you can have the build failing. And, if the build is failing, Jenkins (or whatever your CI is) won't deploy.

Answer 4

As others have pointed out, if your programmers are already out to cheat coding practices, using better coverage tools won't solve your problem. They can be out cheated as well.

You need to sit down with your team and have an honest talk with them about professionalism and what software engineering is supposed to be.

In my experience, code reviews are great but they need to happen before the code is committed. But for that to work in a project where people are 'cheating', you'll need to at least have a reviewer you can trust.

Answer 5

http://pitest.org/ is a good solution for so called "mutation testing":

Faults (or mutations) are automatically seeded into your code, then your tests are run. If your tests fail then the mutation is killed, if your tests pass then the mutation lived.

The quality of your tests can be gauged from the percentage of mutations killed.

The good thing is that you can easyli use it in conjunction with maven, jenkins and ... SonarQube !