An Assertions-DSL in Scala

As I am currently working on some Java code, I am writing unit tests in JUnit and using the quite helpful Assertions and Matchers library Hamcrest. Hamcrest improves assertions by providing matcher to check, whether a current results matches an expectation. It allows the construction of complex logical statements, that are actually not regular Java expressions, but rather runtime expression trees. A benefit of this matchers over conventional assertions is, that they can provide much better error messages. Visit the Hamcrest project website to get more insights in this helpful and slim framework.

Unfortunately Java restricts the design of matcher libraries by not allowing operator overloading and new infix operators. In Scala it is possible to improve the readability of assertions a lot. The following code shows some assertions in Scala:

import matcher.Assertion._;

object MatcherTest {
  def main(args : Array[String]) : Unit = {
    val x = 5;
    val varX = variable("x", x);
    assertThat(varX.==(5));
    assertThat((varX == 6).or(varX == 5));
    assertThat((varX == 6) or (varX == 7) or (varX == 8));
    val s = "test";
    val varS = variable("s", s);
    assertThat(varS.==("t"));
    assertThat((varS == "tz") or (varS == "rd"));
    assertThat((varS == "t") or ((varX == 5) and (varX == 8)));
  }
}

This is all valid Scala code. In Scala it is allowed to use regular methods as infix operators.

Actually instead of raising an exception assertThat just prints the error message:

Expected that (((x == 6) or (x == 7)) or (x == 8))
Expected that (s == t)
Expected that ((s == tz) or (s == rd))
Expected that ((s == t) or ((x == 5) and (x == 8)))

The following code block is a basic implementation. Every expression subclass implements a method to pretty print itself and a method to evaluate whether the expectation is met.

object Assertion {
  def assertThat(expression : Expression) = {
    if (!expression.evaluate) {
      println("Expected that "+expression.text);
    }
  }

  def variable[T](name : String, x : T) = new Variable[T](name, x)
  
  protected abstract class Expression {
    def evaluate : boolean 
    def text : String = "("+textInternal+")"
    def textInternal : String
    def or(expression : Expression) = new Or(this, expression);
  }
  
  protected class Variable[T](name : String, x : T) {
    def ==(y:T) = new Equals(this, y);
    def getX = x;
    def text = name;
  }
  
  protected class Equals[T](v : Variable[T], x : T) extends Expression {
    def evaluate = v.getX == x;
    def textInternal = v.text + " == " + x;
  }
  
  protected class Or(e1 : Expression, e2 : Expression) extends Expression {
    def evaluate = e1.evaluate || e2.evaluate;
    def textInternal = e1.text + " or " + e2.text;
  }
}

There is still a piece of RY (Repeat Yourself) in the code. In fact I had no idea how to avoid the construction of the named variable. Perhaps some Scala gurus can give me a hint.

Update: Context-free in Scala

After reviewing my implementation in Scala I discovered, that both Scala and Java implementation allow method chains like a().a().b().a().b().b(). In fact the presented grammar only allows words starting with n calls of a() and ending with n calls of b().

Here is a patched version of the code:

object AbLanguage {  
  def a = new AfterABase
  
  protected class AfterBBase {
    def b = {}
  }
  
  protected class AfterABase extends AfterBBase {
    def a = new AfterA[AfterBBase](this)    
  }
  
  protected class AfterB[T](sourroundingExpression : T) {
    def b = sourroundingExpression
  }
  
  protected class AfterA[T](sourroundingExpression : T) extends AfterB[T](sourroundingExpression) {
    def a = new AfterA[AfterB[T]](this)
  }
  
  def main(args : Array[String]) : Unit = {   
    a b;
    ((a a) b) b;
    a.a.b.b;
  }
}

The return type of method a() itself allows a further call of a(), instead of that the enclosed type does not have a method a().

Context-free in Scala

With less code than in Java the AbLanguage in Scala:

object AbLanguage {  
  def a = new AOpenedBase()
  
  protected class AOpenedBase {
    def a = new AOpened[AOpenedBase](this)    
    def b = {}
  }
  
  protected class AOpened[T](surroundingExpression : T) {
    def a = new AOpened[AOpened[T]](this)
    def b = surroundingExpression
  }
  
  def main(args : Array[String]) : Unit = {   
    a b;
    ((a a) b) b;
    a.a.b.b;
  }
}

More than regular

This post discusses, whether it is possible to build more than regular languages with method chaining in Java.

Ray Myers suggested in his post Fluent Interface Grammars: Part II (Chaining), that the use of pure method chaining restricts you to regular languages. In fact this seems to be right for Java without generic types. He considered a simple non-regular language:

S ::= a B
S ::= a S B
B ::= b

The compiler should check, whether a sentence corresponds to the language or not. E.g. it should be possible to compile the following:

AbLanguage.a().a().b().b();

This should raise an error:

AbLanguage.a().a().b().b().b();

So we need at least a static method a(). It should return a type, that provides methods a() and b().

public static AbLanguage.AOpenedBase a() {
return new AOpenedBase();
}

public static class AOpenedBase {
public AOpened<AOpenedBase> a() {
return new AOpened<AOpenedBase>(this);
}

public void b() { 
}
}

The implementation and return type of method b() are self explaining. It just finishes the sentence. Method a() shows how to (ab)use the generic type system to count its calls on compiler level.

public static class AOpened<T> {
public final T surroundingExpression;

public AOpened(T se) {
surroundingExpression = se;
}

public AOpened<AOpened<T>> a() {
return new AOpened<AOpened<T>>(this);
}

public T b() {
return surroundingExpression;
}
}

Every call of a() surrounds the given type with a further layer. In the opposite way b() unwraps one layer.

This technique enables us to build bracketed expressions with free depth on top of method chaining . By the way it is fairly complex to build even simple grammars and the code is not really obvious.