Currently I'm enforcing minimum JUnit total coverage on a module level. So if the total line coverage is below a certain value (80% in my case) then the build fails. For that I've used maven-surefire-plugin with maven-enforcer-plugin, JUnit and JMockit. The pom file partially looks like this.
<build>
<plugins>
....
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.18.1</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-junit4</artifactId>
<version>2.18.1</version>
</dependency>
</dependencies>
<configuration>
<systemPropertyVariables>
<coverage-outputDir>${basedir}/target/coverageReport</coverage-outputDir>
<coverage-output>html,merge</coverage-output>
<coverage-check>80</coverage-check>
</systemPropertyVariables>
</configuration>
</plugin>
<plugin>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<id>coverage.check</id>
<goals>
<goal>enforce</goal>
</goals>
<phase>test</phase>
<configuration>
<rules>
<requireFilesDontExist>
<files>
<file>coverage.check.failed</file>
</files>
</requireFilesDontExist>
</rules>
</configuration>
</execution>
</executions>
</plugin>
....
</build>
<dependencies>
....
<dependency>
<groupId>org.jmockit</groupId>
<artifactId>jmockit</artifactId>
<version>1.17</version>
</dependency>
<dependency>
<groupId>org.jmockit</groupId>
<artifactId>jmockit-coverage</artifactId>
<version>1.17</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
</dependency>
....
</dependencies>
My problem is that, Some classes might be very much below 80% coverage and the build still pass as long as the total coverage isn't below 80%.
So, Is there any way I can enforce my coverage on a class level?
Giving you an opinionated non-answer: don't do that. Don't make your build fail on missed coverage numbers!
Here are reasons to back that up: you are trying to solve a social problem using technical means.
Your real problem is: you want to achieve certain code quality, and you think you get that by punishing people when they don't comply. That will not really work. Sooner or later, people will start to bypass this idea. They will look out for quick ways to "just make the build" happy; ignoring your idea of improving code quality by asking for reasonable code coverage. Or some manager comes at you, pointing out that the new feature/fix is right now more important that the current coverage goal. Then what? Disable the check temporarily? Allow for a lower number?
Of course, measuring coverage of unit tests is a good thing. You should do that often, and make it easy for your developers to access this information (for example by putting it on some dashboard). It is also fair to ask your DEV teams to commit to certain goals. But forcing some coverage number down everybody's throat ... will not work out.
(Well: if you are working in a high class environment, where each developer not only accepts your idea but fully supports you; then things might be different. But if you would be living in such an environment, then high coverage would come by itself; without enforcing it).