The Code Coverage Paradox

As a software architect I’m constantly exposed to people quoting high code coverage metrics as a measure of test quality.  Eh, no… A code coverage metric is not a measure of test quality!  Code coverage provides an ability to determine what parts of your application are not tested.  It has no value at all in determining how well tested your application is.  After all, it’s not particularly difficult to obtain high code coverage metrics without providing any degree of testing.

Thus the paradox is, a lower code coverage metric is actually more valuable than a high one; as it provides more guidance in what needs to be tested.  In fact I would argue, it’s hard to imagine a code coverage value of over 70% to be of any value whatsoever.  Code coverage only measures the degree of your application exercised within the context of a unit test, not whether anything is actually being tested.  Some people would argue that just exercising code within the context of a unit test is testing the code.  It isn’t.  But it is a mechanism that’s frequently used as a scheme to get high code coverage values.

At present, there is no automated mechanism for determining unit test quality.  I suspect a mechanism rather like the code quality metrics such as cyclomatic complexity etc. will be the eventually obtain some degree of measurement of automated test quality.  Right now, there’s nothing.  The whole area of automated testing is constantly mutating with techniques like IoC, mock objects and parameterized tests surfacing every few years to revise what’s considered best practice.

In short, if someone quotes a figure of 100% for code coverage for a non-trivial application one might be forgiven for thinking he’s either a liar or an idiot and quite possibly both.


Leave a comment

copy-maven-plugin missing required class “org.sonatype.aether.RepositorySystem”

Today, when I tried to build one of our existing projects Maven gave me the following error:

[ERROR] Failed to execute goal com.github.goldin:copy-maven-plugin:0.2.5:copy ...
com.github.goldin:copy-maven-plugin:0.2.5:copy failed: A required class was missing while executing
com.github.goldin:copy-maven-plugin:0.2.5:copy: Lorg/sonatype/aether/RepositorySystem;

Read the rest of this entry »

, , ,

Leave a comment

Where is Scala’s “break” Keyword?

Does Scala have the break keyword?

The short answer is “No”. Scala doesn’t support break and continue at the language level. However it provides you with the right API calls to achieve the same results.
Read the rest of this entry »

, ,

Leave a comment

Putting manners on JavaScript

Everyone writing web applications at some point has a run in with JavaScript. Frankly, it’s ugly, it’s dynamically typed and not really object orientated.
I’m one of the old school who likes statically type variables (at least by default anyway).
Recently I’ve adopted using TypeScript, an open source language from Microsoft for putting manners on larger scale JavaScript projects.  TypeScript is a superset of JavaScript (For the more nerdy, ECMAScript 6 is their target).  As a result, it runs with just about anything that runs JavaScript, even node.js.  When combined with good IDE integration it’s a really good experience.
A while back I had to construct a technology demonstrator relying heavily on JavaScript, that amounted to a single page application.  I got it finished to my satisfaction, but I was never really happy with the JavaScript.  My “objects” were rudimentary, my functions ugly and it had too many code smells.  I wish I’d known about TypeScript.  My most recent project is heavily dependent on JavaScript and with the use of TypeScript a much cleaner prospect.  I’m using interfaces, small classes and most importantly inferred static typing (awesome!).  When I save it’s automatically compiled to plain old JavaScript.


Leave a comment

gitignore Files… Are You Still Creating Them Manually?

Do you use Git? Do you create your .gitignore files manually?

If yes, here is an on-line tool that can make your life easier. Read the rest of this entry »

, , , , , , ,

Leave a comment

Better Type Inference in Java 8 Generics

Java 7 gave us the diamond operator:

  Map<String, String> dict = new HashMap<>();

The code above doesn’t duplicate the type parameters unnecessarily as it made perfect sense to extend type inference to instantiation. Now Java 8 pushes type inference a little further. Read the rest of this entry »

, , ,

Leave a comment

Java 8 Lambda Expressions Capture Values, Not Variables

Before Java 8, when we needed to use a local variable inside an anonymous inner class, the local variable had to be declared final:

public class ValueCaptureAnon {
  public static void main(String[] args) {
    String name = "Yagiz"; //Compile error in Java 7...

    Runnable runnable = new Runnable() {
      public void run() {
        System.out.println("Name is " + name);

Read the rest of this entry »

, , , ,