Style Guide vs. Unit Test: Mocking final classes and methods

If you use for example the rule DesignForExtension from Checkstyle most of your classes and public methods should be declared final. The keyword final defines that those classes and methods can’t be extended. But how would you mock such a class or method? A mock object simulate a object by mimic the behavior of a real object in controlled ways. To achieve this it overwrites every method from a real object. But remember that final classes and methods can’t be overwritten. Take this example:

public final class SomeClass {
	public String getSomeValue() {
		return "Example";
	}
}

public final class SomeUtilClass {
	public static void doSomething(SomeClass sc) {
		// Do something ...
	}
}

SomeClass sc = new SomeClass();
SomeUtilClass.doSomething(sc);

How would you test SomeUtilClass.doSomething()? The expected class SomeClass is final and you can’t use a mock object. I think that the problem is not that SomeClass is final. I think the problem is a wrong code design. If you change SomeUtilClass.doSomething() to accept an interface instead of a concrete class there is no problem anymore. All you have to do is to extract an interface:

public interface SomeInterface {
	String getSomeValue();
}

public final class SomeClass implements SomeInterface  {
	public String getSomeValue() {
		return "Example";
	}
}

public final class SomeUtilClass {
	public static void doSomething(SomeInterface sc) {
		// Do something ...
	}
}

SomeClass sc = new SomeClass();
SomeUtilClass.doSomething(sc);
Twitter Facebook Delicious

15. April 2012 by Sven Kiera
Categories: Style Guide vs. Unit Test | Tags: , , , , | Leave a comment

PHP Tool Integration (PTI) 2.0

Currently it is not easy to submit a bug or a feature request for my project PHP Tool Integration (PTI), so I get every now and then e-mails in relation to it. I am also not satisfied with the current PHP Tool Integration hompage, which offers no easy access to information. Since I also have some problems with the old code of PTI , I have decided to start working on PHP Tool Integration 2.0, which will be provide the following features:

New code base

I started to build PHP Tool Integration on a complete new code base to provide more stability, more features and for me easier development ;-). Furthermore I want to switch to Maven/Tycho to provide continuous integration, nightly builds and automatic generated updates for library plugins like PEAR.

New features

A want to provide not only PHP tool related features like a code template management or remote test execution.

New homepage

The new home of PHP Tool Integration will be Github! So you will have easier access to the source code, a help system and documentations. And it will be easier for you to contribute to the project ;-)

I hope you like it and stay tuned :-)

Twitter Facebook Delicious

11. February 2012 by Sven Kiera
Categories: PHP Tool Integration (PTI) | Tags: , , , , , , | 3 comments

Style Guide vs. Unit Test: Code Coverage

In some situations you have to decide what is more important: style guide or unit tests. Checkstyle has for example a check for hiding class constructors by utility classes. This forces you to add a non public constructor for classes with only static methods. Take this example:

public class MyUtilClass {
   public static String callMe() {
      return "some text";
   }
}

To pass this check you have to add a non public constructor:

public class MyUtilClass {
   private MyUtilClass {
   }

   public static String callMe() {
      return "some text";
   }
}

If you want to reach 100% code coverage you have to test every executable line of code. Since constructors counts as executable lines you have to test it. But would you test an empty private constructor? If yes you have to provide a method which creates a instance of that class. A better way can be found in the documentation which use a protected constructor with an exception. Here is an example with corresponding unit test:

public class MyUtilClass {
   protected MyUtilClass {
      throw new UnsupportedOperationException();
   }

   public static String callMe() {
      return "some text";
   }
}

public class MyUtilClassTest {
   @Test(expected = UnsupportedOperationException.class)
   public final void testNoInstantiation() {
      new MyUtilClass() {};
   }
}

One little “problem” with this is that someone can extend this class, but I can live with that. And think twice if you make your methods final.

Twitter Facebook Delicious

01. February 2012 by Sven Kiera
Categories: Style Guide vs. Unit Test | Tags: , , | Leave a comment

Style Guide vs. Unit Test: Final War

To check our source code we use Checkstyle which provides for example some rules to validate your class design. During writing of JUnit tests I stumble upon a problem with the final keyword. Final defines that something cannot be changed later and some Checkstyle rules  check if you use it as often as you can. If you make your methods or classes final you can be sure that no one can modify class or its behavior. But what if you want to use mock objects? Take the following examples (I use Mockito as mocking framework for Java):

public class MyClass {
   public final String testMe() {
      return "one";
   }
}

import org.junit.Assert;
import org.junit.Test;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

public class MyClassTest {
   @Test
   public void testTestMe() {
      MyClass mock = mock(MyClass.class);
      when(mock.testMe()).thenReturn("two");
      Assert.assertEquals("two", mock.testMe());
   }
}

You get something like this:

org.mockito.exceptions.misusing.MissingMethodInvocationException:
when() requires an argument which has to be 'a method call on a mock'.
For example:
    when(mock.getArticles()).thenReturn(articles);

Also, this error might show up because:
1. you stub either of: final/private/equals()/hashCode() methods.
   Those methods *cannot* be stubbed/verified.
2. inside when() you don't call method on mock but on some other object.

In this situation you get a error message and you know that something went wrong. But I had to check that a object is not modified and I used something like this:

public class MyClass {
   public final String testMe() {
      return "one";
   }
}

import org.junit.Test;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verifyZeroInteractions;

public class MyClassTest {
   @Test
   public void testTestMe() {
      MyClass mock = mock(MyClass.class);
      mock.testMe(); // object interaction
      verifyZeroInteractions(mock);
   }
}

Since testMe() is final and cannot be overwritten by Mockito, Mickito cannot check if there is any interaction and the test will not fail. So beware of final methods and classes, even if tests does not fail that did not mean nothing went wrong. So think twice if you make something final and you should always let your tests fail to test your tests.

Twitter Facebook Delicious

29. January 2012 by Sven Kiera
Categories: Style Guide vs. Unit Test | Tags: , , , , | Leave a comment