[rspec-users] inverse examples? (should fail)

Chris Anderson jchris at mfdz.com
Sat Jun 23 16:42:21 EDT 2007

Thanks for the pointer about rspec-ext, I'll check it out.

On 6/23/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> As for including this in rspec, I'm not really understanding it's
> value. How would saying something should fail, and failing it if it
> doesn't, help you (unless you're writing another behaviour definition
> framework ;) )?

Not having done it yet, I'm not sure how it would pan out in practice,
but the notion is that you're refactoring to change existing behavior.
 You've got a describe-block, and among the examples are a few that no
longer apply.

With the objective of maintaining behaviour-driven development, I
don't want to change any code without a failing spec. One helpful way
to do that would be with inverse examples.

It seems like a 5% case - even most behaviour-changing refactorings
force the old behaviour to change, but there have been times I've run
into old examples, that are passing, and supported by code. But that
code is not used anywhere in the application - so the behaviour should
have been removed long ago. With inverse examples, you can start a
refactor by removing the behaviour you know should not be present. If
you just delete the examples, there's no reason to ever delete the
vestigial code.

I'll check out the negative specification - the post you link to has
another interesting idea - write negative specs as a form of pending -
but I think forcing changes via the inverting of existing examples is
more up my alley.

Chris Anderson

More information about the rspec-users mailing list