ActiveTest – Instantiation, mocking, and injection for the lazy

David Saff wrote in on Introducing MagicTest, asking why not just instantiate the variable in-line (private Foo foo = new Foo();).

Which brings me to the real reason for coming up with MagicTest—ActiveTest.

A code sample is worth a thousand words. Suppose we have a Spring JPA data access object:

public class WidgetDao extends JpaDaoSupport {

  @Autowired
  public WidgetDao(final EntityManager entityManager) {
    setEntityManager(entityManager);
  }

  public Widget find(long id) {
    return getJpaTemplate().find(Widget.class, id);
  }

}

WidgetDao needs a JPA EntityManager provided to it at construction time. Normally, to write a unit test for WidgetDao we’d have to create our mock objects and setup our test harness manually.

Using ActiveTest, however, all we need to write is:

public class WidgetDaoTest extends ActiveTest<WidgetDao> {

  private WidgetDao widgetDao;

  @Mock
  private EntityManager em;

  @Test
  public void testFind() {
    widgetDao.find(42);
    Mockit.verify(em).find(Widget.class, 42);
  }

}

I’m lazy like that.

Introducing MagicTest

If you’ve written enough JUnit 4 tests, then you should be familiar with code that looks like:

public class FooTest {

  private Foo foo;

  @Before
  public void setUp() {
    foo = new Foo();
  }

  @Test
  public void testBar() {
    assertTrue(foo.bar());
  }
}

Now, how often have you wished it were possible to simply go straight to @Test, do not pass setUp(), do not have to new Foo()?

Introducing MagicTest

So I came up with MagicTest, a parameterized base class for JUnit 4 tests that’ll let us do just that.

Shell script to uninstall (MacPorts) ports and any dependents

If you use MacPorts, then at some point you’ve probably tried to uninstall a port that had other ports as dependents. (If you’re a developer on OS X and you don’t use MacPorts, then you probably should.)

Even when using a friendly GUI like, say, Porticus, you’re prevented from uninstalling a port with dependents. Of course, you can force uninstall a port but MacPorts themselves warn us that doing so might cause problems later on (when rebuilding the dependents).

So, I used to manually traverse down the dependency tree and uninstall the leaf nodes (ports with no dependents) one by one until I could uninstall the ‘root’ port that I wanted to uninstall in the first place.

If you like doing that, then by all means keep doing so.

If, like me, you’re tired of having to do it by hand, then here’s a short shell script I wrote that can do all that for you.

Determining the type parameter of a generic base class

The following code is provided for educational/illustrative purposes only.

This is probably just a clever hack. This is not kosher. To all students of the Java language, please do not start using this in your day-to-day code. Let me be the first to admit that I haven’t used this extensively and I wouldn’t recommend using it for production.

Disclaimers aside, I won’t give any more background into Java generics. For those in need of an introduction, Angelika Langer’s Java Generics FAQ explains a lot of things with more clarity and depth than I ever could.

The basic problem is, given a generic class, we would like to determine the type parameter to that class at run-time..

I’ve found myself needing to do this more than once. The simplest example I can contrive is one when we want the Base class to perform run-time type-checking of some input parameter.

Creating and using a Derby datasource in JBoss 4.2.3.GA on Java 5

Spent a good part of today digging through various mailing list and JIRA posts just to get this to work so I figured I’d post about it for other people who might run into the same problems.

The difference between theory and practice…

Google for “jboss derby” and the first link should be SetUpADerbyDatasource [DOC-12234] over at jboss.org.

That is basically the same file under
${JBOSS_HOME}/docs/examples/jca/derby-ds.xml.

Ji-Woong Choi was kind enough to point out some things that were missing, and to cut a long story short I’ll just post the (supposedly) working derby-ds.xml right here:

Quartz 1.6.0 Maven2 pom.xml

Here’s a quick post for those who a) use Maven 2 and b) need to use Quartz 1.6.0 in their projects.

See now Quartz 1.6.0 has (run-time) dependencies on JTA (if you’re using it stand-alone, outside of a J2EE container) and Commons Collections – unfortunately, the Quartz pom.xml doesn’t specify these as dependencies.

So here’s a pom.xml you can use to base your project’s POM off from.

Maven2 Ant Plugin cannot be found

If you use Maven 2, and have been trying to use the Maven 2 Ant plugin (”mvn ant:ant“), you may have been getting the following error:

The plugin 'org.apache.maven.plugins:maven-ant-plugin' does not exist or no valid version could be found

A quick check, however, at the Maven 2 Plugin Repository shows that the maven-ant-plugin is right there. However, the latest published version is version 2.0 and for some strange reason (at least on my end) Maven doesn’t pick it up.

There is a workaround. Apparently, you can specify the full plug-in groupId, artifactId and version as mentioned in here in the maven-users mailing list. So you could go:

mvn org.apache.maven.plugins:maven-ant-plugin:2.0:ant

Better yet, simply configure the plugin through in your project’s pom.xml:

<build>
  <plugins>
  ...
    <plugin>
      <artifactId>maven-ant-plugin</artifactId>
      <version>2.0</version>
    </plugin>
  ...
  </plugins>
  ...
</build>

(Note that the plugin groupId, when not specified, defaults to org.apache.maven.plugins which is correct, in this case.)

That should let you do mvn ant:ant again any time!

Magic Beans in Ruby

One of the nice things about Ruby is how it lets you do ‘meta-programming’. Specifically, through the included(base), class_eval, and define_method methods available in the Module module, we can write code that seems to magically write other code for us!

Querying an XML document using XMLStarlet

I use Maven to manage my Java build process. Maven, like Ant, uses XML to store information about your project and how to build it.

Yesterday, a thought occurred to me – What if I wanted to write a script that would do post-packaging of the Maven-built artifact(s)?

For example, what if I wanted to take the Maven-built artifact and distribute it via an OS X disk image? Or even something as simple as packaging the source into a tar.gz?

A simple shell script would be easy enough to cook up – but without repeating myself, how could I do it such that the subsequent packages are named according to the same version declared in the Maven pom.xml file?

This got me to thinking about how to query XML, possibly using XPath from a shell script or the command line. I thought I might have to roll out my own XML-XPath command line processor, but fortunately somebody else beat me to it (thanks, God for all the wonderful people on teh internets) with XMLStarlet.

Using the Subversion Ruby Bindings

I work with a distributed team of Ruby (on Rails) developers, and we use Subversion as our repository of choice. Just recently, I wanted to find out which files were recently changed or added to a particular directory of our project.

Doing it manually would’ve been tedious. I also wanted to do it with code so that maybe sometime in the future we might be able to script some behavior depending on the last changed date of a file or group of files in our repository.

I could’ve resorted to merely calling svn info and parsing its output, but I thought maybe this was a good excuse to sharpen my Ruby chops and figure out the Subversion Ruby bindings.