Archive for July, 2009
Testing Abstract Classes With Mockito and JUnit
Posted by rn in General, Java, Software Engineering on July 28th, 2009
Often times in Java, you have an abstract parent class which has some concrete methods which call abstract methods which will be implemented by the child classes.
So what’s an easy way to test this sort of pattern?
A mock is not an appropriate solution, since we don’t want to mock our abstract class, we want to provide an implemention of the abstract methods, which we can mock to test the logic of the parent class.
There is a neat solution to this problem, using the great mocking framework for Java – Mockito -
public abstract class MyAbstract {
public String concrete() {
return abstractMethod();
}
public abstract String abstractMethod();
}
public class MyAbstractImpl extends MyAbstract {
public String abstractMethod() {
// we have to provide an implementation that will run without error
return null;
}
}
public class MyAbstractTest extends TestCase {
public void testConcrete() {
MyAbstractImpl abstractImpl = spy(new MyAbstractImpl());
doReturn("Blah").when(abstractImpl).abstractMethod();
assertTrue("Blah".equals(abstractImpl.concrete()));
}
}
So what’s going on here?
Well Mockito (1.8+) implements a “spy” feature which doesn’t mock the object, it creates a “spy” wrapper around the real method implementations. This allows us to override the return values / exception behaviour of some methods, but leave other methods to implement their usual behaviour.
In the code above, we override the abstractMethod() which is part of the implementation class, to test the concrete() method in our abstract class. Of course, usually the abstract class would be doing something more interesting than simply returning the implementor’s value, and so we would implement tests in the ususal fashion to test the different code paths in our concrete() method.
5 Reasons Why NetBeans Rocks
Posted by rn in General, Java, Software Engineering on July 25th, 2009
I’m a long time NetBeans user, but I’m still surprised how many developers still haven’t given it a go. Certainly there was a time in the deep distant past when NetBeans couldn’t compete at the same level as Eclipse or IntelliJ, but NetBeans has been a first rate IDE for a long time now.
Read on for 5 features that might not be obvious to someone test-driving NetBeans for the first time…
#1 Project Local Libraries
Ticking the innocent looking “”Use Dedicated Folder for Storing Libraries” checkbox on creating a new Java project will simplify project portability down to a complete non-issue. All JAR dependancies are stored in the “lib” folder underneath your project and are automatically copied to the distribution folder at build time. You can guarantee to take your project to any machine and run the build with Ant (or NetBeans) and it just works.

#2 Customisable Ant Builds
NetBeans uses Ant (by default) for managing all aspects of building, running, testing and documenting your Java projects. And while the builds are machine-generated they’re not impossible to read and work with.
However, you don’t even need to modify the NetBeans generated build logic – there are a whole bunch of “override points” in the build logic in which you can embed new logic, or override the default behaviour.
And since NetBeans uses Ant to build, deploy and run, you can guarantee that if it worked in your IDE, then it’ll work on the build server or anywhere else you want to build the project.

#3 Built-in Profiler
The built in Java code profiler in NetBeans kicks ass. There are certainly equally useful, or better, tools available commericially, but for a pain-free out-of-the-box experience, the NetBeans profiler is great.
Features include -
- Real-time display of run-time profiling
- Filtering of profiled classes
- Memory usage and garbage collection stats
- Saveable profiling results for future comparisons
- Low barrier to entry – very straightforward and simple to get started

#4 Refactoring Tools
The refactoring tools are exactly what you would expect and allow you to move, rename and safely delete any code element as you need. The “Introduce Method” is particularly useful for refactoring code blocks that start to get a little too large. “Introduce Method” is probably not the logical name (it was renamed from “Extract Method”) but it does the job none-the-less.

#5 Call Hierarchy
Tucked away in the context menu is the under-rated “Call Hierarchy” tool. Right click on any method and invoke the tool and immediately see all the callers, and their call stacks. Flip the switch and see the call stack that this method makes to other methods. This one tool can give you a very fast detailed understanding of what a method’s dependancies are. It’s a great way of coming up to speed on a code base without doing heaps of opening, closing of files and manual “eye-balling”.


