TDP - Test driven plumbing

The other day I got a new washing machine installed in my house. After the first wash I noticed a small puddle of water on the floor below where the washing machine was connected to ingoing water and outgoing wastewater. I had a bug in my plumbing.

Being test driven and all I figured I first had to device a test that would indicate I had fixed the leak. I tied a piece of cloth around the joint to the ingoing water and one around the joint to for the wastewater. I ran the machine ones more and observed both cloths getting wet. I removed the cloths and tightened the joints. Tied a dry piece of cloth around each joint and ran the machine a third time. This time the cloths were dry.

I could have left the cloths there. Then I would even have had a regression test indicates which joint was leaking in case of a new leak, but I removed them, relying on the test to check on the floor for puddles.

JUnit Max Evaluation

I have been using JUnit Max for a few weeks now. And feel like I am ready to do an evaluation of it.

The benefits of JUnit Max are numerous.

• Tests are run faster than when you usually do when using the internal Eclipse JUnit runner, since it starts automatically upon saving a file.
• More tests are run during regular development as it eventually will run all my tests for the project I am working on. When running tests manually I tend to run only a subset of tests since running tests is interrupting my coding, and I want the interruptions to be as short as possible. This makes me find unexpected side effects sooner.
• JUnit gui of Eclipse have quite a few problems, specially with showing the actual fail message. JUnit max shows the message both in the problems view, and as a "compile error" with a tooltip. Which makes the actual error easier to read.
• To get full use of JUnit Max you will, even more, experience the benefit of quick unit tests. Since you will be addicted to getting your test results quickly. You would not want to wait minutes for your IDE compiler, and you will eventually not want to wait for the test errors to show either.
• There is no fuzz in getting it to run. If you can run your tests within Eclipse, JUnit Max can run them too.

I see only two problems, and they are rather minor.

• JUnit Max adds a little bit of extra load on your development machine, if you are on the limit of what your workstation can perform this might be a problem. Upgrade your equipment!
• JUnit Max costs money. In a professional environment, this should be no problem, since the costs of this software is minor compared to the cost of paying the developer to wait for tests to run.

 To conclude. JUnit Max will make you work more effectively, and is worth the 100$/year it costs. Go get it!

http://junitmax.com

JUnit Max

I have started to look at Kent Beck's latest creation, JUnit Max (http://www.junitmax.com). And it is looking really promising.

JUnit Max is an Eclipse plugin that run your junit test cases in the background, just as eclipse compile your code in the background. And like the compiler, JUnit Max adds those small red icons to the margin of your editor window, and also reports the test failures as problems. On my crap laptop, the load on the system is not noticeable. The results however are not as fast as the compiler responses. But still way faster than to run the usual JUnit tool in Eclipse.

I do not know yet if is worth the $100 per year fee, but I intend to find out.

Continous Deployment

He might look like a punk rocker who has worn his DocMartens a few yours too many, but he is making some interesting claims.

http://saucelabs.com/blog/index.php/2009/09/continuous-deployment%E2%80%94the-video/

Watch it!

The joy of TDD

During the last few weeks of work I have been working on a small web service app. The work has been done a bit on the side since I had more urgent tasks to attend to, but had some time to spare once in a while. While coding the service, which is not too complex and consists of some thousand lines of code, I worked by the motto of not adding or changing a line of code unless it helped me passing a unit test. I also set out a strategy for myself to test every detail in detail, and test that system composition was done properly, but I had no tests that exercised the whole service. Yesterday I installed the service for the first time on a web server and performed the first manual test call. It worked flawlessly.

Back in the saddle

After + a year of parental leave I am back programming. Listening to
Software Engineering Radio interview with Kent Beck

The Duct tape programmer debate

On Joel Spolsky's blogg, Joel On Software a few days ago there was a post called The Duct Tape Programmer. He had read a book with an interview with a former Netscape programmer called Jamie Zawinski, who he found to be an amazing programmer working in a manner that Spolsky appreciated. Spolsky gave Zawinski the title Duct Tape Programmer for his way of solving problems in stead of engineering them. He ranted about 'architecture astronauts' who make things too complicated etc. In the debate after the article the actual "Duct Tape Programmer", Jamie Zawinski, stated that Spolsky had gotten most of it wrong (that "duct tape" silliness), but anyhow the post contains some important things.

Here are my thoughts, when I trying to interpret what Joel Spolsky writes in a positive way.

The base property of a duct tape programmer is the ability do things in a simple manner. eXtreme programming has this as one of it's first rules of software design. But after that fact, the aspects of duct tape programmers that Joel Spolsky so highly admire, are hard to appreciate. Not doing unit tests will not make you deliver a working product sooner. Being a good craftsman is beneficial in programming as in any business, but when someone is going key board cow boy on a project, the mess made will still be substantial, no matter the programmers skill. Succeeding at a programming project is about cooperation, not about duct tape.