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();

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

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.

This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to Test-Driven Development for Epsilon

  1. Pingback: Test-Driven Development for Epsilon « Eclipse, Java and more

  2. Pingback: New in Epsilon 0.8.5 « Epsilon Weblog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s