Blog

Testing private methods

I've always been convinced by XP practices and thus by unit testing. However I only started doing it on a daily basis when moving to Ireland.
I now have 18 months experience in that field and therefore a bit of hindsight. One of the main concern I had at the beginning was how to test private methods.
I have tested several approaches until I've found one that is satisfying. In this post I will present them and explain their drawbacks.

Declare the methods as protected

More hashcode tricks

I’ve already spoken of the importance of implementing haschCode() along with equals(). In today’s post I will show how breaking the second point of the hashCode() contract can have significant effects. This point is:
If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result. (see: http://download.oracle.com/javase/7/docs/api/java/lang/Object.html#hashC...).

Careful with anyObject() !

When you start unit testing massively you code you will soon run into some dependency issues. If your code is well structured and respects the the dependency inversion principle you should be able to those dependencies. Mocito and EasyMock are the most popular framework for Java. I personally use EasyMock and I find it very useful. However there I discovered a tricky thing with its matchers. One of them is anyObject() which obviously accepts any kind of object as a parameter to a method.

Filtering Findbugs report by Rank

I wish I was posting more often on my blog. I have several things I want to speak about but I'm short of time. Anyway I was explaining how tricky the priority and rank are with Findbugs in an earlier post. The problem arises when you want to filter your report by rank and one of the solution is to grab a snapshot version of the library. That's decent enough but sometimes you might not be able to do so or you might want to stick to final releases.

What's wrong with this class (hashcode, equals)?

public class Animal {

private int id;

@Override
public int hashCode() {
  final int prime = 31;
  int result = 1;
  result = prime * result + (id ^ (id >>> 32));
  return result;
}

Ant and Hudson are not displaying the same priority for Findbugs warning?

If you are using Findbugs and Hudson at the same time you might have noticed something strange. The ant task and the Hudson plugin are not assigning the same priorities to bugs. In the ant task you have a reportLevel parameter which can be set to low, medium or high. On the Hudson dashboard you also have you’re bugs displayed as low, normal or high. But setting reportLevel to medium for instance might display some low priority bugs in the dashboard. Very weird isn’t it?

Code coverage is not sufficient

Having the highest line coverage and branch coverage has now become a critical issue in most of the projects. In some of the projects you include a point in the Definition of Done so that you don't fall below a certain threshold. This is definitely a good approach but has some drawbacks. Writing some tests that will always pass just for the sake of increasing the code coverage is one them. You might also end up with your build broken without having enough information to fix it. To tackle this you can set-up some code reviews or work in pairs.

What the hell is this Util class?

I haven't been writing a blog post in ages. That's very unfortunate but I've been really busy in the last few weeks.
Today I want to speak about something that you can see in every project, the Util class.
And I will start with this piece of advise: this class should not exist.

Don't repeat yourself!
The first reason why this class should never exist comes down to the old DRY principle.
In several projects I got a chance to work on I've seen an awful lot of duplicated methods.
For instance:

public boolean isEmpty(String value) {

The boy scout is refactoring...

My last post about refactoring was explaining why you should refactor as often as possible but that you might end up with a testing issue. One of the way to bypass this impediment is known as the scout rule. This comes back from the latest letter written by Robert Baden-Powell to the Scouts where he said "Try and leave this world a little better than you found it". This was rephrased later as "Always leave the campground cleaner than you found it". Can we get inspired by this quote when developing software?

Don't write them!

I'm currently reading Peter Mc Breen book Software Craftmanship. It's a very interesting book about what software engineering is and why it is failing too often to deliver valuable software to end users.
One of the sentence that stroke me particularly is the following: "It is practically impossible to be precise in English (or any other language)". This was about the software requirements and why the development team and the users should talk to each other to avoid any misinterpretations.

Syndicate content