(Post)modern software development


Software development is fast becoming a configuration activity (“plumbing” as I like to call it), with many simple applications requiring very little true programming. There’s nothing fundamentally wrong with this “plug it together” approach - it’s been working well for Unix scripting for 30 years - and we should be happy that we’re getting this level of relatively easy reuse. However, increasingly often you find yourself at a loss to make all the fragmentary bits of software stick together to make a system.

Recently, I tried to port Ivan Moore’s tool Jester (a JUnit test tester) to C#. What Jester does is quite clever, but isn’t particularly complicated. It just mutates Java source code using some simple predefined rules and runs a suite of JUnit tests. C# is syntactically very similar to Java, NUnit does the same job as JUnit, so you’d think it would be easy to port to C# and NUnit, wouldn’t you?

Round 1–promising start

Starting from a clean machine, I began by downloading the .Net framework and installing it. Then I downloaded Java and installed that. Then I downloaded Jester and NUnit. So far so good. Even with broadband, Java and .Net take ages to download - don’t get me started on bloated programming languages or we’ll be here all week. Time taken (I estimate) 90 minutes. I wasn’t measuring too carefully at this point, as I was expecting everything to go smoothly from here on in.

I’ve never used .Net or C# before so I had to spend a couple of hours working out how to use the compiler, set up paths and so on. No real problems.

Next was NUnit, which seems to be a bit bigger and more complicated than JUnit. Nevertheless, it wasn’t difficult to set up, and I had a few simple unit tests running in under an hour.

Round 2–Java voodoo

Then Java. I ended up speaking to Adewale Oshineye at the Extreme Tuesday Club about this. Java could find the class file for “Object”, which is a bit of a showstopper. I’ve seen this before but couldn’t for the life of me remember what caused it. Ade pointed out that Sun installs programs called “java” all over your system. He pointed out 3 different ones to me. Why, why, why do we need 3 different programs called Java installed? And why can’t the installer put the right one on the path? Anyway, I could then make some progress again. Discounting the time spent talking to Ade, I guess this cost me about another hour.

Round 3–Surely you Jest?

Jester was next. I needed to know this was working. I tried it on some simple JUnit tests. It worked. Excellent! Less than one hour. This ease of working turns out to be short-lived though.

Then I started looking through the source code for Jester, the Python port of Jester (Pester) and NUnit to figure out a neat way of implementing C#ester. After perhaps 2 hours trawling through code and documentation I concluded that the best way is to write a small XSLT stylesheet that makes NUnit’s output conform to what Jester expects, and ask NUnit to apply the stylesheet to its own output. Actually writing this took 5 minutes and it worked first time. Next, I wrote some configuration and batch files to wrap things up a little more neatly. Probably about 10 minutes for the lot.

Round 4–Success almost within reach…

At this point I felt I was ready to give it a try. I wrote a simple NUnit test and some code that is untested. C#ester should spot this. Then I tried to run it, and this is where my problems really began.

Jester refused to read my configuration files and kept trying to use run tests using JUnit instead of NUnit. After a couple of mails to Ivan we got this down to a Java classpath error. But even with the correct directory on the classpath and no other configuration files anywhere that could interfere with Jester’s reading of my configuration file, it still didn’t work. Another hour gone.

Round 5–Serious hacking begins…

In desperation, I cracked open jester.jar to make sure there was no configuration file lurking in there, but there wasn’t. I started Eclipse and loaded in the Jester source code. It contains some fallback values, so I changed the fallbacks to hardcode the values I wanted and exported the new jester.jar.

Round 6–Configuration problems

Then it worked! Well, it ran NUnit, but backslashes were getting stripped from pathnames and files weren’t being found. Annoying but easy to fix. Another quick change in Eclipse, export and… nothing. In fact, no further changes to jester.jar had any effect on C#ester’s overall performance. I struggled with this for perhaps another hour before it dawned on me that after the first export, Jester had been finding my configuration file. So I changed the configuration file to add superfluous backslashes, and finally, mercifully, it worked.

Estimated time spent: 10.5 hours on getting the bits to talk to each other, 15 minutes on writing the actual code for the application, and most of that was configuration files. This is modern software development in a nutshell. Sometimes I wonder whether this constitutes an improvement over the old days!