TDD with FireOtter

James Earl Douglas

June 11, 2013

Motivation

Testing is good for testing
Specifications are good for specifying
Is one good for the other?

Motivation

A simple test

test("1 + 1 = 2") {
  val input1 = 1
  val input2 = 1
  val expectedOutput = 2
  val output = Arithmetic.add(input1, input2)
  assert(output === expectedOutput)
}

A simple specification

The Arithmetic#add function produces the sum of two integers.

Motivation

Test code is a side-effect of test specification

Usually happens only implicitly
Specification is reverse-engineered by reading the test code
Vulnerable to misinterpretation and forgetfulness

Motivation

Let's produce our tests before (or without) coding them.

test	function	input	expected output
1 + 1 = 2	add	1, 1	2

Technical overview

package com.versal.fireotter

def csv(path: String): Traversable[Seq[String]]

import com.versal.fireotter._

val specs: Traversable[Seq[String]] = csv(resource("arithmetic.csv"))

specs foreach { spec =&gt;
  // Seq[String] =&gt; extract testable inputs, expected output
  test(spec(0)) { assert(output === expectedOutput) }
}

Technical overview

Wait, isn't this just a CSV parser?

Yeah, pretty much.

What's benefit of following this pattern?

Test specifications are tangible, and transcend implementation details.

Demo

TDD with FireOtter

github.com/Versal/kawauso

github.com/Versal/fireotter