Rails - Sep 2006 - 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!).


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On Wednesday 20 September 2006 22:34,
ljredpath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
[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

-- 
Michael Schuerig
mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org
http://www.schuerig.de/michael/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

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.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On Thursday 21 September 2006 14:30,
ljredpath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> 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

-- 
Michael Schuerig
mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org
http://www.schuerig.de/michael/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

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?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On Thursday 21 September 2006 15:52,
ljredpath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> OK, how does this syntax work for you:
>
> specification :user do
>   requires_presence_of :username, :password
>   requires_confirmation_of :password
> end
Much better :-)

Michael

-- 
Michael Schuerig
mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org
http://www.schuerig.de/michael/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

OK I''ve committed this API change to subversion.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I like it!! I think that it is more understandable that the validations
that come with rails.

Keep the good work!

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---