ActiveSpec - Ruby Specifications library (preview)

Hi Guys

Over the past week (well, since RailsConf finished) I've been working
on a Ruby Specifications library called ActiveSpec, with the aim to
provide an alternative to Rails validations module (though ActiveSpec
can be used outside of Rails apps too).

What is ActiveSpec?

It is an implementation of the Specification domain pattern. ActiveSpec
provides built-in low-level specification classes (that mostly mirror
Rails' validates_* macros) and a few extras like composite specs and a
spec negator decorator. It provides a more declarative way of creating
composite specs, with the ActiveSpec::Base class, and finally it
provides a high-level DSL for creating specifications. What does that
DSL look like?

specification :user do
  should_require_presence_of :username, :password
  should_require_confirmation_of :password
end

You can also do a form of specification inheritance:

specification :authenticated_user do
  should_satisfy :user_specification # the above spec
end

You can even uses Ruby procs for quick, arbitrary specs:

specification :foo do
  should_satisfy { |obj| # do something }
end

Finally there is the Satisfies module which makes attaching specs
directly to your classes (including ActiveRecord classes), a breeze:

ActiveRecord::Base.send(:include, ActiveSpec::Satisfies)

class User < ActiveRecord::Base
  should_satisfy :user_specification
  should_satisfy :activated_user_specification, :if => :activated?
end

Why ActiveSpec?

Rails' validates_* macros are awesome but sometimes you want a bit more
power, and using the lower level validate methods is a bit icky. More
importantly, as we found out on a recent project with a particularly
complex domain model, you sometimes want to validate your model in
different ways depending on its state or what context it is being used
in. Its hard to do this elegantly with Rails' current validations API.

Is it ready to use?

Not quite, but theres enough there to check out and start playing with.
The major thing that it is lacking that Rails validations have, is
error messages. This *will* be added but I haven't tackled it yet. But
I'd love people to check out the trunk and have a play and provide me
with some feedback at this early stage.

Where can I find it?

You can grab the source code from the Agile Evolved open source
repository:
http://opensource.agileevolved.com/svn/root/activespec/trunk/

You can check out the RDocs here:
http://docs.britsonrails.org.uk/activespec/

I've tried to fully document the API as best as I can. There's also a
README file there with more information.

License?

MIT, natch!

Have fun, let me know how you get on!

(by the way, if you want to know more about the Specification pattern
beyond what google tells you, I cannot recommend Domain Driven Design
by Eric Evans enough!).

Hooray...finally a post of mine shows up on the Rails google group. :slight_smile:

[snip]

specification :user do
  should_require_presence_of :username, :password
  should_require_confirmation_of :password
end

[snip]

class User < ActiveRecord::Base
  should_satisfy :user_specification
  should_satisfy :activated_user_specification, :if => :activated?
end

I think the terminology is rather odd. It is apparently inspired by
behavio(u)r-driven design, but goes over board with it. BDD makes sense
in an executable specification where you state what a thing is
intended -- "should" -- to do and check it at the same time. But in the
thing itself you state what it does do.

When I read code such as the excerpts above, I stumble. Hey, this User
class should satisfy some specification -- but does it really? What I
expect instead is

  satisfies :user_specification

Then I happily leave it to the tests to determine whether this claim is
true and the class really satisfies the specifications it, well,
should.

Michael

Hi Michael,

I'm afraid you've misunderstood me when I say this was influenced by
RSpec - this has nothing to do with BDD whatsoever. Specification is a
well established domain pattern. This is all about making sure your
object satisfies certain conditions *at runtime*. Your tests don't come
into it. Your specifications are a core part of your domain model, not
your underlying tests (specs, in RSpecs case).

You say "should satisfy" rather than "satisfies" as the object might
not always satisfy a particular spec, and thats ok. The best way of
describing it is to look at it as souped up validation. However, whilst
the should_satisfy and satisfies_specs? methods give you a bit of
syntatic sugar, tthe specifications are decoupled from the objects that
you are trying to validate. Furthermore, Specifications are *not*
limited to the task of validating objects. They can also be used to
find objects that meet a particular specification. There is an example
of that here:

http://www.mattberther.com/?p=612

There is some great information on the Specification pattern in chapter
9 of Domain Driven Design.

There is also a 19 page paper by Martin Fowler on the specification
pattern. Here's a small quote:

"The central idea of Specification is to separate the statement of how
to match a candidate, from the candidate object that it is matched
against. As well as its usefulness in selection, it is also valuable
for validation and for building to order. "

http://www.martinfowler.com/apsupp/spec.pdf

Hi Michael,

I'm afraid you've misunderstood me when I say this was influenced by
RSpec - this has nothing to do with BDD whatsoever.

I don't think so... as I don't remember reading that you were influenced
by RSpec. I made up the connection to BDD entirely on my own based on
the naming convention you're using in ActiveSpec.

Specification is
a well established domain pattern. This is all about making sure your
object satisfies certain conditions *at runtime*. Your tests don't
come into it. Your specifications are a core part of your domain
model, not your underlying tests (specs, in RSpecs case).

Yes, I know, I've just looked it up again in DDD[*]. I think I was being
to dense regarding tests in my previous message. Let's try again. It is
okay when a test or a requirements specification (i.e. not the pattern
incarnation) writes in terms of what some thing *should* do. That's
what happens in BDD, for instance.

In the implementation of something I find it distracting and misleading
to use "should". Would anyone in their right mind write something like

  my_file.should_open(...)

I don't think so. Open the damn file or die trying, i.e. raise an
exception. There's just no place for "should" in here.

You say "should satisfy" rather than "satisfies" as the object might
not always satisfy a particular spec, and thats ok.

Yes, it is okay if an object doesn't satisfy a specification. Half the
world's population doesn't satisfy the specification is_female? (xor
is_male?). I'd feel just too hard pressed to imagine the specification
should_be_female (should_be_male). No. Specifications express
predicates, boolean-valued functions. Is or is not, either or.

Also, "should satisfy" is not as neutral as you make it out. In ordinary
parlance it is not ok if something violates(!) a specification or
requirement that it *should* satisfy.

[*]

There is some great information on the Specification pattern in
chapter 9 of Domain Driven Design.

Incidentally, Eric Evans never uses the "should_" prefix in his
examples.

So, to wrap up, please eradicate the shoulds. I really fear there's a
nascent "should" craze coming upon us in the wake of BDD. I'm doing my
best to stamp it out as early as I can.

Michael

OK, how does this syntax work for you:

specification :user do
  requires_presence_of :username, :password
  requires_confirmation_of :password
end

You can also do a form of specification inheritance:

specification :authenticated_user do
  must_satisfy :user_specification # the above spec
end

Incidentally, I've already checked in one API change...Specifications
now use satisfied_by? instead of pass?

Much better :slight_smile:

Michael

OK I've committed this API change to subversion.