Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Using maven and jenkins, how to test the programmers did some test cases?

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.

like image 818
techsjs2013 Avatar asked Feb 05 '13 14:02

techsjs2013


People also ask

How do I run a test case in Maven?

We can run our unit tests with Maven by using the command: mvn clean test. When we run this command at command prompt, we should see that the Maven Surefire Plugin runs our unit tests. We can now create a Maven project that compiles and runs unit tests which use JUnit 5.

How does Maven work with Jenkins?

Jenkins allows you to run Maven, and decide when to call a POM file, what condition to call, and what to do with the outcome. And since Jenkins can listen to different events, e.g svn commit, the current time is 12:00 AM, etc. Jenkins and Maven can become quite a powerful duo.


2 Answers

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, 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.

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)

like image 195
Stephen Connolly Avatar answered Oct 23 '22 09:10

Stephen Connolly


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.

like image 43
Mark O'Connor Avatar answered Oct 23 '22 09:10

Mark O'Connor