Java Reference
In-Depth Information
stack
.
push
(
2
);
stack
.
push
(
1
);
expect
.
that
(
stack
.
pop
()).
isEqualTo
(
2
);
});
});
}}
We start off our suite of specifications using the
describe
verb. Then we give our suite a
name that tells us what it's describing the behavior of; here, we've picked
"a stack"
.
Each of specifications reads as closely to an English sentence as possible. They all start with
the prefix
it.should
, with
it
referring to the object whose behavior we're describing. There
is then a plain English sentence that tells us what the behavior is that we're thinking about.
We can then describe expectations of the behavior of our object, which all start with the
ex-
pect.that
prefix.
When we check our specifications, we get a simple command-line report that tells us which
pass or fail. You'll notice that “pop the last element pushed onto the stack” expected
pop
to
be equal to
2
, not
1
, so it has failed:
a stack
should pop the last element pushed onto the stack[expected:
but was: ]
should be empty when created
should push new elements onto the top of the stack
How We Got There
So now that you've seen the kind of fluency we can get in our DSLs using lambda expres-
sions, let's have a look at how I implemented the framework under the hood. Hopefully this
will give you an idea of how easy it is to implement this kind of framework yourself.
The first thing I saw when I started describing behavior was the
describe
verb. This is
really just a statically imported method. It creates an instance of our
Description
class for
the suite and delegates handling the specification to it. The
Description
class corresponds
Example 8-29. The describe method that starts the definition of a specification
