> <i>Tests are specifications</i><p>No, they're not. Unless you're OK with the system working for only exactly the test cases you specify (which, btw, is trivially implementable as a look-up table of the test cases!), tests <i>do not</i> specify a system.<p>EDIT: Importantly, tests have no means of distinguishing for a missing test case whether that case's behavior should be <i>inferred</i> or is <i>actually unspecified</i>.<p>See <a href="http://en.wikipedia.org/wiki/Z_notation" rel="nofollow">http://en.wikipedia.org/wiki/Z_notation</a> for an example of an actual serious specification language.
An interesting alternative to this is Spock [1], a specification framework for Java and Groovy with a nice Groovy DSL. Check out the new reference documentation [2] or try out some specifications using the web console [3].<p>It has a great syntax for data driven and interaction based syntax.<p>Data driven example:<p><pre><code> class Math extends Specification {
def "maximum of two numbers"(int a, int b, int c) {
expect:
Math.max(a, b) == c
where:
a | b | c
1 | 3 | 3
7 | 4 | 4
0 | 0 | 0
}
}
</code></pre>
[1] <a href="https://code.google.com/p/spock/" rel="nofollow">https://code.google.com/p/spock/</a><p>[2] <a href="http://docs.spockframework.org/en/latest/" rel="nofollow">http://docs.spockframework.org/en/latest/</a><p>[3] <a href="http://meetspock.appspot.com/" rel="nofollow">http://meetspock.appspot.com/</a>
There is this odd trend amongst testing framework developers to make their frameworks more verbose, as if this somehow delivers value. Spek seems to be in this tradition. Almost every other area of programming aims towards getting as much work done with as a little verbiage as possible. Why do testing framework people feel that programs should read like written prose? This idea has failed a great many times over the years.<p>The ScalaCheck [0] library is actually innovating in the domain of testing. It's derived from QuickCheck, a Haskell library, and I believe an Erlang derivative is making $$s as a commercial product.<p>[0]: <a href="https://github.com/rickynils/scalacheck" rel="nofollow">https://github.com/rickynils/scalacheck</a>
Name and functionality inspired by Spec# [0] ... just a bit? Sample Spec# code:<p><pre><code> int ISqrt(int x)
requires 0 <= x;
ensures result*result <= x && x < (result+1)*(result+1);
{
int r = 0;
while ((r+1)*(r+1) <= x)
invariant r*r <= x;
{
r++;
}
return r;
}
</code></pre>
[0] <a href="http://research.microsoft.com/en-us/projects/specsharp/" rel="nofollow">http://research.microsoft.com/en-us/projects/specsharp/</a>
Building tooling like this seems a no-brainer as far as language uptake is concerned.<p>Testing libraries offer a low friction, low risk way to introduce new JVM based languages to an existing project.<p>Scalatest was certainly Scala's "foot in the door" for the last project where we managed to sell the switch from Java to Scala.<p>On a related note: I would really like to see an in depth comparison between Scala and Kotlin. The two seem idealogically and syntactically similar.
This seems to be influenced by MSpec [0] which is a really elegant framework. I'm not sure if I like having to use Kotlin, though.<p>[0] <a href="https://github.com/machine/machine.specifications" rel="nofollow">https://github.com/machine/machine.specifications</a>
I am not sure if something like Jasmine or Chai exists in the JVM world but this seems pretty similar. You can do much the same thing with BDD-style describe() and it() specs.
FYI: "spek" is Dutch for "bacon" — <a href="http://nl.wikipedia.org/wiki/Spek" rel="nofollow">http://nl.wikipedia.org/wiki/Spek</a>.