Trying to produce bad quality code is quite hard when you are using Test Driven Development (TDD), even when you are doing it wrong on purpose.
Recently Iwein and me were preparing some labs for a developer training and the plan was to create some really bad quality Java code as a starting point. Students would then be asked to clean it up and add some new features, all this of course with the intent to show the effect of bad code quality on your ability to quickly add new features. This was going to be a piece of cake!
After some brainstorming for interesting standalone programming challenges, we came up with the idea of writing a JSON to XML converter. It should be able to take any valid JSON string and convert it into a simple XML representation. Out of habit and without really considering the option of skipping this step, we started with a simple failing test. Here it is:
@Test
public void shouldConvertTopLevelEmptyArray() {
assertThat(converter.convert("[]"), is("<array></array>"));
}
Simple, right? To implement our converter we decided to use the well known “red, green, as little refactoring as possible” anti-pattern, which we expected to result in lots of copy-paste duplication, very long methods, and the other typical code smells we all know and loath. Our first implementation approach was to go for some all-time favorite candidates for producing bad code: string manipulation and regular expressions. As Jamie Zawinski famously said: “When some people have a problem, they think: ‘I know, I’ll use regular expressions’. Then they have two problems.” We had created a sure thing recipe for disaster. It was going to be all downhill from here, or so we thought.