Digital Digressions by Stuart Sierra

From programming to everything else

Lazytest Churn

Posted on by Stuart

One of my stated goals with Lazytest was to enforce a clean separation between test assertions and code that runs before/around the assertions.

The Spock framework for Java/Groovy calls these the stimulus and response, identified by the keywords when and then, respectively. I find this approach attractive, but one look at Spock’s documentation shows it’s thoroughly embedded in the imperative mode:

when:
stack.push(elem)

then:
!stack.empty
stack.size() == 1
stack.peek() == elem

In my last Lazytest update, I added the expect macro, which signals failure by throwing an exception. That was useful for adding typed “reason for failure” objects to the test results, but not good in that it led me back in the direction of allowing arbitrary code in test examples.

After todays’ commits, the expect macro is still there, but you don’t use it explicitly. I’ve reverted to allowing only a single test expression inside the it macro. That expression will automatically be wrapped in expect.

If you really need to execute arbitrary code in an example, use the new do-it macro, and call expect explicitly.

Hopefully this is explained clearly enough in the new README.

5 Replies to “Lazytest Churn”

  2. Previously, it was quite easy to throw typed exceptions from custom functions. Would be happy to hear your insight on the following issues:

    a) Would you consider the expectation map of vars in lazytest.expect, an extension mechanism for adding custom expectations? So, it’s ok for users to add to it?

    b) How would one re-use some expectations for different objects/fixtures? Imagine a case, where you’d want to assert common expectations a given protocol for different implementations. Right now, I would have to call a function inside a do-it, which would then call various expects.

    ps: enjoyed the colors on the report! currently, using a multi-term buffer (w/ black background) on emacs, and looks good.

  3. liked it, because it requires less typing.

    do you plan to keep the given and using macros to use Fixtures as they are now? I’m curious, because I’m already making use of them ;)

  4. Pedro- ‘given’ and ‘using’ will probably stick around, though my latest commits make them unusable outside of ‘describe’.

    One possibility I’m considering is unifying ‘given’ and ‘using’ under a single name.

Comments are closed.