ActiveSpec - Ruby Specifications library (preview)

rubyonrails-talk
1

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:

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!).

2

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

3

[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

4

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:

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

5

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

6

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

7

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?

8

Much better :slight_smile:

Michael

9

OK I've committed this API change to subversion.