If every line of untested code is like Schrödinger’s cat – Potentially dead or alive – how important is it to ‘open the box’ properly and know for sure if the code will leap out and run?
The perceived wisdom that if a piece of code hasn’t been tested you can assume it won’t work, is proof – if any were needed – that coders will always expect the worst case scenario when creating code. Unlike Schrödinger, a coder will not waste time mulling over the metaphysical possibilities of whether their code might be dead or alive or even dead AND alive at the same time – they need certainty, and as quickly as possible. However any amount of testing will only be worthwhile if the quality of that testing is high. In this blog Yannick Mayeur, a Kichwa Coders intern, describes how he kept his fur on whilst improving the testing coverage of Eclipse January.
An introduction to JUnit
This week I was reintroduced to JUnit, having forgotten most of what I had learned about it at the University Institute of Technology back home. JUnit is a unit testing framework. It is used to test the different methods of a program to see whether or not the intended behaviour is working. It is often said that a method that is not tested is a method full of bugs, and after a week of testing I can confirm that this saying is indeed grounded in truth.
My job this week was to improve the test coverage of Eclipse January. You can calculate the coverage of a program using the EclEmma plug-in. I worked on the DatasetUtils class, improving the coverage from 47% to almost 58%, and fixing bugs using two methods: (https://github.com/eclipse/january/pull/178 and https://github.com/eclipse/january/pull/188).
Seeing that bugs can exist in untested code written by people that know a lot more about what they are doing than I do, really showed me the importance of testing.
How I did it
This is a test I have written for the method “crossings”. Writing this test helped me highlight some unexpected behaviour in the way it works.
@Test
public void testCrossings3() {
Dataset yAxis = DatasetFactory.createFromObject(new Double[] {
0.5, 1.1, 0.9, 1.5 });
Dataset xAxis = DatasetFactory.createFromObject(new Double[] {
1.0, 2.0, 3.0, 4.0 });
List<Double> expected = new ArrayList<Double>();
expected.add(2.5);
List<Double> actual = DatasetUtils.crossings(xAxis, yAxis, 1,
0.5);
assertEquals(expected, actual);
}
This shows what the values look like: 
The expected behaviour of the method as written in the test would be that the 3 crossing points would be merged into one at 2.5, but this wasn’t what was happening, indeed the code was using “>” instead of “>=”. If left untested this code’s bug would probably never have been discovered.
Conclusion
Discovering bugs like this one is crucial. When users employ this method they are almost certainly expecting the same behaviour that I was, and therefore won’t understand why their code isn’t working – especially if they can’t see the original code of the method and only have access to its Javadoc. I hope that correcting bugs like this one will create a smoother user experience for coders in the future.
Kichwa Coders 