Reimplementing Length Unit Converter in Java

Back in April I did a programming exercise in Python, which I really enjoyed and resulted in PyCLU and its Jenkins node, I was slightly sorry not to set up the Jenkins node earlier in the process, so the coverage graphs do not start at zero.

Today I received the same exercise with the option of implementing in Python or Java, so I have decided to reimplement in Java, rather than reuse my python implementation.

Setup

Following Project Initiation Recipe

Choose short name

JCLU

Choose stack

This will be a pure java command line application. It will be built using Maven on OpenJDK 7, with version compatibility set to 1.6, this was initially 1.4, but revised in the light of use of annotations within the testing code. It would be possible to use 1.4 in the artefact code and 1.6 within the testing code, should that become a requirement.

Create Repo

The only decision is public or private. It will be a git repo: here.

Choose CI

My Jenkins.

Setup dev machine

My dev machine has been set up according to this Ubuntu Setup Recipe.

Checkout and create Maven project from archetype

Now we have a buildable artefact.

Setup on Jenkins

Nice and early on, so that we can see test coverage evolve. Here

Diversion to reimplement RDD in Java

In the Python implementation I added an iteration of Requirements Driven Development (RDD), a utility born out of the audit driven culture of the NHS.

Annotating each test with which requirements it addresses enables a tighter coupling between requirements and tests.

RDD fits into the evolution of Agile programming by analogy with one of the justifications for Test Driven Development:

Why are you writing code?

To make a test pass

How do you know when to stop?

When all tests pass

The motivation behind RDD similarly:

Why are you writing that test?

To satisfy requirement ref X

How do you know when to stop?

When all requirements are tested

Another motivation, and tie-in with general Agile principles, is that it ties documentation to the code: the requirements grow when new tests are written as unforeseen requirements surface.

In PyCLU I used annotations, this should be possible in java (I have not written a java annotation before).

The idea is that a dated Requirements Verification Document will be produced by running the tests, that the tests will fail if there is an unmet requirement and the document can be published by Jenkins: here.

Ready to start

Quite a lot of work just to get to the starting line!

Translated PyCLU into java, adding only one test, that the wrong number of arguments throws an exception and that the specified input produces the specified output. This showed the slight differences in the specification: JCLU does not need to output the full name of the unit, does not accept multiple units eg 1 yd 3 in and does not need to add units. Removed unspecified code. This achieves 100% code coverage.

Now to test the requirements!

Reintroduce equals() and hashCode() for testing.

Convert all relevant tests from PyCLU; add tests for unused but needed hashCode() and equals().

Add tests for units not in PyCLU.

Review and submit!