Test-Driven Development for Epsilon

Test-Driven Development (TDD) is an approach to software development that advocates writing tests before implementation. TDD has many advantages when compared to other forms of development, in which tests are often an after-thought. Proponents argue that TDD produces clean interfaces, minimal implementations and a suite of tests that can be used to guard against regressions. (See “TDD by Example,” Beck and, to some extent, “Refactoring,” Fowler).

In the past, we’ve been reluctant to construct automated unit tests for Epsilon, largely because we lacked structures and processes for constructing and checking models in the context of a testing framework, such as jUnit.

Since developing HUTN, we’ve been discovering/inventing/hallucinating patterns for constructing and checking models that allowed us to construct tests that were readable and malleable. This week, we wanted to make an enhancement to EOL, and, using these patterns, I was able to do so in a (more) test-driven manner.

EOL defines distinct operators for comparing expressions and for performing assignment. The concrete syntax is = for the former and := for the latter. We’ve found that we’ve had a few reports of code like the following:

var a : Integer;
a = 2;

EOL compares a and 2 in the second line, rather than assigning a to 2.

We decided that we could change EOL to rewrite statements whose first operator was = to an equivalent statement whose first operator was :=

I started by defining some tests that exercised the EOL execution engine with the old behaviour and with the new behaviour:

private static final EolEvaluator evaluator = new EolEvaluator();

@Test
public void assignment() {
	evaluator.execute("var a; a := 1 + 2;");
	assertEquals(new EolInteger(3), evaluator.evaluate("a"));
}

@Test
public void equalityActsAsAssignment() {
	evaluator.execute("var a; a = 1 + 2;");
	assertEquals(new EolInteger(3), evaluator.evaluate("a"));
}

I’m using the EolEvaluator class, which decorates the EOL execution engine and can be used to execute small snippets of EOL code.

The first test passed, and the second test failed as expected. Typically, we’d now define some unit tests on the unit that needs to change to accommodate those changes, but I’ll leave that as an exercise for your imagination.

Crucially, because I’d used TDD, I felt comfortable editing a piece of code that I’d not developed, and never touched before – I had tests that verified (to some extent) my work. Plus, we’ve got tests that guard against regression in this part of EOL.

---

Possibly related posts: (automatically generated)

• a testing dilemma
• TDD – Test Driven Development
• Is pure TDD practical?
• Tebow still taking some post-concussion tests