Finding unreferenced JUnit Tests in Eclipse

When working with JUnit 3.8.x, one usually has a TestSuite (often named AllTests), which contains all indivdual test cases of a Java Project. Especially when dealing with a large number of projects, it is hard to ensure that every single test case is included in an AllTests suite. Sometimes one encounters a test case and wonders why it is not executed on the continuous integration server. However in most cases, one just won't recognize.

I wrote a little Eclipse plug-in that addresses this issue. It searches all projects for test cases that don't have any references in the workspace.

The search for unreferenced tests can be started from the Search menu:






















Here is what the result dialog looks like:












The plug-in can be downloaded here.

Notes: This plug-in is not applicable to JUnit 4; The plug-in does not handle more complicated scenarios, e.g. a hierarchy of TestSuites.

Extreme Feedback Device

Recently, I read about Extreme Feedback Devices (e.g. lava lamps).

The idea is to set up a physical device that displays the current status of an automated build in an eye-catching way, so that it is really hard to not recognize that the build is down. I loved the idea and decided we have to have an Extreme Feedback Device (XFD) on our own.

I wanted an especially cheap and simple solution. I used a mySmartControl M8 board with an ATMega8 AVR RISC microcontroller from Atmel, modified the circuit of a cheap LED effect lamp and connected it to the microcontroller, so that each color can be switched on and off individually.

The microcontroller board has an USB interface and shows up as a virtual COM port. A small C program running on to the microcontroller listens to commands sent via the COM port from the PC and reacts by switching the LEDs on and off. On the PC a Java programm polls the web page of the build server and sends commands to the microcontroller utilizing the serial communication library rxtx.

The price for the hardware was about 35€. It took me 5 hours to make everything work, whereas the hardest part was the microcontroller programming. Luckily there was a ready-to-use example program which exactly did what I needed :-)

Here is what the final result looks like:














After using the device for a couple of days it turned out to be very useful, if the device flashes a couple of times when the state changes, so that one recognizes a build failure immediately, even from the corner of one's eye.
As the device has also a blue LED, and can therefore display basically arbitrary colors by mixing the primary colors (RGB), one can think of visualizing additional aspects of the build status.

TDD cycle length

In theory, a Test Driven Development cycle constists of the following steps:

• Write a new failing test
• Run the test and see it fail
  
• Code (in order to pass the test)
• Run the test again and see it pass
• Refactor
  

In literature the time for one TDD cycle is stated to be about a couple of minutes.

I was wondering how my personal cycle time is at an average. So I wrote a little plug-in for Eclipse that listens to test runs and computes the average time between a test run with failures and a test run without any failures.

Here is what the very simple plug-in looks like:













In case you want to give it a try you can download it here.
The plug-in contributes a view called TddMeter. In order to show it simply hit <CTRL>-<3> and type TddMeter.

Note: The plug-in requires Eclipse 3.3

Update: The plug-in now persists its state.