
Spek – A Specification Framework - hhariri
http://jetbrains.github.io/spek
======
colanderman
> _Tests are specifications_

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 _do not_ specify a system.

EDIT: Importantly, tests have no means of distinguishing for a missing test
case whether that case's behavior should be _inferred_ or is _actually
unspecified_.

See
[http://en.wikipedia.org/wiki/Z_notation](http://en.wikipedia.org/wiki/Z_notation)
for an example of an actual serious specification language.

~~~
thatthatis
There's nothing that says any non trivial specification in any language is
either complete or correct.

Tests _can be_ used as a _kind of_ specification.

~~~
timtadh
> nothing that says any non trivial specification in any language is either
> complete or correct.

Absolutely correct. In fact the larger the specification the more likely that
the specification has a bug.

> Tests _can be_ used as a _kind of_ specification.

Also true. But, frequently in program verification (proving a program does
what it is specified to do) specifications are not tests.

Why are specification not written as tests? It comes down to the program
verification technique which is used. There are several categories:

\- Testing. "Optimistically Inaccurate" It can't find all problems but all
problems it finds are real problems (assuming of course the test is correct).
The downside is you may give an OK to a bad program, the upside is when you
find a problem it is a real problem.

\- Dataflow Analysis. "Pessimistically Inaccurate" It can prove fairly general
properties about a program. However, it cannot prove all properties and may
not be able to prove a property which is true. For example say you where
proving a program did not have a SQL injection. Dataflow analysis would OK
only programs it could prove the absence of a SQL injections (as per the
specification you give it! (there may be a SQL injection your spec doesn't
cover)). However, there may be programs which are free of SQL injections but
Dataflow Analysis is unable to prove it.

\- Model Checking. "Pessimistically Inaccurate, Simplified Properties" In
model checking you move the program by mapping it into a new domain such as a
finite state automaton. You do the mapping in such a way that properties
proved about the model must hold in the actual program. Unfortunately, you can
only check simplified properties and there is still some pessimistic
inaccuracy (although it is reduced from dataflow analysis since the domain is
easier to prove properties on).

\- Syntax Analysis. "Simplified Properties" Eg. Grammar Checking. You can only
prove properties that can be found by a parser. You can write checks which
have false positives. Eg. the check may fail but the program is fine.

Type Checking is another method way as is Theorem Proving. I am sure there are
even more methods beyond the ones I listed here.

The point is except in the case of testing, the specifications are not given
as tests. Each verification technique requires its own formal specification
language. However, there are some systems where you can specify a program in a
general language which can then be compiled to the verification system you
actually use.

------
frederikb
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].

It has a great syntax for data driven and interaction based syntax.

Data driven example:

    
    
      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
        }
      } 
    

[1] [https://code.google.com/p/spock/](https://code.google.com/p/spock/)

[2]
[http://docs.spockframework.org/en/latest/](http://docs.spockframework.org/en/latest/)

[3] [http://meetspock.appspot.com/](http://meetspock.appspot.com/)

~~~
vorg
> It has a great syntax for data driven and interaction based syntax.

With DSL's in groovy it always looks like the provided syntax is trying to
code around Groovy's syntactic limitations, e.g. having to use the bar | in
the example

    
    
        a | b | c
        1 | 3 | 3
        7 | 4 | 4

------
noelwelsh
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.

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.

[0]:
[https://github.com/rickynils/scalacheck](https://github.com/rickynils/scalacheck)

~~~
ams6110
There's this idea that tests can be written by non-programmers (QA, business
SMEs, etc.) which may be the motivator for this. Just a guess.

I used a framework called FitNesse which was awful but which was built around
this idea that tests could all be specified in spreadsheets and managed by
non-technical folks.

~~~
hhariri
I'd hope not. I think developers should write tests. And I think things like
BDD is more about communication than anything else.

The difference is however in using a language that is ubiquitous and
understood by all parties, leaving ambiguity out. It is about contrasting what
you've understood in terms of the requirement with what is expressed in the
code.

------
biot
Name and functionality inspired by Spec# [0] ... just a bit? Sample Spec#
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;
      }
    

[0] [http://research.microsoft.com/en-
us/projects/specsharp/](http://research.microsoft.com/en-
us/projects/specsharp/)

~~~
farginay
Different thing. Spec# is about embedding specs in your code. Spek appears to
be a Behaviour Driven Development (BDD) framework ala RSpec.

[http://rspec.info/](http://rspec.info/)

------
hugofirth
Building tooling like this seems a no-brainer as far as language uptake is
concerned.

Testing libraries offer a low friction, low risk way to introduce new JVM
based languages to an existing project.

Scalatest was certainly Scala's "foot in the door" for the last project where
we managed to sell the switch from Java to Scala.

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.

------
royjacobs
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.

[0]
[https://github.com/machine/machine.specifications](https://github.com/machine/machine.specifications)

------
badman_ting
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.

------
WimLeers
FYI: "spek" is Dutch for "bacon" —
[http://nl.wikipedia.org/wiki/Spek](http://nl.wikipedia.org/wiki/Spek).

~~~
davidw
That's pretty close to this:

[http://en.wikipedia.org/wiki/Tyrolean_Speck](http://en.wikipedia.org/wiki/Tyrolean_Speck)

Which is delicious.

------
louisdefunes
Funny but Python code is more readable than their DSL !

------
jackgavigan
There's already a perfectly good language for creating specifications:
English.

~~~
rpwilcox
Disagree, there's a lot of ambiguity in English that makes for bad
specifications.

Example: take even the word "tomorrow". Does tomorrow mean at midnight
tonight, or tomorrow morning? Does it mean 24 hours from _now_ , or does it
mean a far future time? Does "tomorrow" include weekends or holidays? In what
timezone is this happening?

The Beach Boy's song: "Will you love me tomorrow?": Is that asking if the
singers love will still have the same feelings about them tomorrow (less than
24 hours from now), or is the singer asking if their love will still adore
them many years from now, (when they're 64, for example, to pick another
oldey).

Which is of course why civilians think developers are pedantic, and of course
we are, because to implement specifications on Turning machines we need to
answer these slightly outrageous questions. "Turn on the sprinkling system
tomorrow" is a trivial specification for a human, but not so for computers.

Tomorrow is just the example that comes to mind, there are thousands of other
words whose meanings are vague. This is why creating specifications for
computers, from "civilian English" is hard.

~~~
jackgavigan
The fact that some people use the language in a vague or unspecific manner
does not invalidate English's suitability as a language for writing specs.

I doubt I've ever used "tomorrow" in a spec. I'd use "next business day" or
"T+1" (with the calendar defined).

In my experience, writing a spec is an iterative process, where the developers
review a draft of the spec and make comments, ask questions, point out
ambiguity, etc., which provides the feedback for the next version off the
spec. That process loops until everyone is happy, at which point the spec (or,
at least, a portion of it) is finalised and the developers start work.

------
sz4kerto
Seems to be very similar to Scalatest. What's not a bad sign.

------
yawz
It funnily looks like scalatest (FunSpec, ShouldMatchers, etc.).

