Hey, we’re currently using shoulda (http://dev.thoughtbot.com/
shoulda/) on a project and I saw some things that would be really nice
to see in rspec, namely the should_ methods, and especially the
should_be_restful method. Do these go against the rspec goals at
all? Or could an ambitious programmer go to town implementing these
for rspec_on_rails?
Nathan S.
[email protected]
rspec 1.1
rspec_on_rails 1.1
rails 2.0.2
On 1/10/08, Nathan S. [email protected] wrote:
Hey, we’re currently using shoulda (http://dev.thoughtbot.com/
shoulda/) on a project and I saw some things that would be really nice
to see in rspec, namely the should_ methods, and especially the
should_be_restful method. Do these go against the rspec goals at
all? Or could an ambitious programmer go to town implementing these
for rspec_on_rails?
The current philosophy is to keep these kinds of things as plugins. A
few of us have started to extract common matchers into a plugin which
can be found at Google Code Archive - Long-term storage for Google Code Project Hosting..
Feel free to submit a patch if we’re missing something that you’d
like.
–
Josh K.
phone: 509-979-1593
email: [email protected]
web: http://joshknowles.com
Hmm, that includes a good number of them, but there’s still the
restful resource to think about, which is in my opinion the most
valuable one. Would you consider the addition of a restful resource
matcher similar to shoulda’s?
Nathan S.
[email protected]
rspec 1.1
rspec_on_rails 1.1
rails 2.0.2
On 1/10/08, Nathan S. [email protected] wrote:
Hmm, that includes a good number of them, but there’s still the
restful resource to think about, which is in my opinion the most
valuable one. Would you consider the addition of a restful resource
matcher similar to shoulda’s?
Yes. If you work something up I’d happily add it. Unfortunately I
don’t have the need/time/desire to do it myself right now though.
–
Josh K.
phone: 509-979-1593
email: [email protected]
web: http://joshknowles.com
We’ll see if I get around to it. It would be a lot of work, I think,
and I know a couple people who have started similar efforts.
Nathan S.
[email protected]
rspec 1.1
rspec_on_rails 1.1
rails 2.0.2
Also, that strikes me as strange that the current philosophy is that
for the rspec_on_rails plugin. I would think rails-specific matchers
would be endorsed at some point, since rails is so big on convention.
Nathan S.
[email protected]
rspec 1.1
rspec_on_rails 1.1
rails 2.0.2
On Jan 10, 2008 5:50 PM, Nathan S. [email protected] wrote:
Also, that strikes me as strange that the current philosophy is that
for the rspec_on_rails plugin. I would think rails-specific matchers
would be endorsed at some point, since rails is so big on convention.
It’s actually quite sane. I’ll give you an example: have_tag. That was
initially implemented completely within RSpec. Rails was a moving
target so it kept breaking. So we changed it to rely on assert_select,
which ships w/ rails. It’s been very stable since, but assert_select
has not been updated with the new features - especially in terms of
rjs, so it is no longer complete.
What I’d really like to see now is that have_tag gets implemented w/
hpricot, but doing so would risk breaking a lot of existing specs.
With a plugin approach, there is no problem. The community can offer
different solutions to different problem sets.
Another issue is BDD philosophy. BDD is about behaviour. should
have_many(:posts) is not behaviour. It is structure. I understand that
there are people who view this differently, and I would not want to
get in the way of anyone using that approach, but RSpec should not be
sporting conveniences, even very pragmatic ones, that fundamentally go
against the grain of BDD.
FWIW,
David
There David goes, making sense again.
Nathan S.
[email protected]
rspec 1.1
rspec_on_rails 1.1
rails 2.0.2
On Jan 10, 2008 6:02 PM, Nathan S. [email protected] wrote:
Nathan S.
[email protected]
rspec 1.1
rspec_on_rails 1.1
rails 2.0.2
I love that your sig has your rspec and rails versions. That cracks me
up.
On Thu, 2008-01-10 at 17:59 -0600, David C. wrote:
Another issue is BDD philosophy. BDD is about behaviour. should
have_many(:posts) is not behaviour. It is structure. I understand that
there are people who view this differently, and I would not want to
get in the way of anyone using that approach, but RSpec should not be
sporting conveniences, even very pragmatic ones, that fundamentally go
against the grain of BDD.
Out of interest, how would/do you test associations David? What if
should have_many(:posts) tested the behaviour of the association rather
than whether it’s defined?
–
Jonathan L.
http://jonathanleighton.com/
Speaking for myself, since I support the same philosophy, I wouldn’t
test the association. I don’t care that it has_many posts. I might
care that I can add multiple posts, or that I can find posts by
criteria, so I would test that.
JD
Hey now! Really though, have you ever been digging through old
mailing lists and wondered which version they were using when they had
that issue? Or when someone posts and issue, you need to ask them
what versions of everything they’re using? It can be a pain and it
usually wastes time/energy, so this is a simple solution. 
Nathan S.
[email protected]
rspec 1.1
rspec_on_rails 1.1
rails 2.0.2
On Jan 10, 2008 6:04 PM, Jonathan L. [email protected]
wrote:
than whether it’s defined?
It has more to do with what I’m looking at in my specs than what lies
under the hood. Why do I care if a visitor has_many(:posts)? Maybe
there is something different about a blogger with no posts vs one with
describe Blogger, “with no posts” do
it “should be completely lame and banned for eternity” do
@blogger.should be_completely_lame_and_banned_for_eternity
end
end
describe Blogger, “with 1000 posts” do
it “should be revered by the community” do
(1…1000).each { @blogger.post(:title => “today’s thoughts”) }
@blogger.should be_revered_by_the_community
end
end
Now we’re talking about behaviour. has_many is implied. No need to
spec it directly - serves no purpose by itself.
That all make sense?
On Jan 10, 2008 6:07 PM, Nathan S. [email protected] wrote:
Hey now! Really though, have you ever been digging through old
mailing lists and wondered which version they were using when they had
that issue? Or when someone posts and issue, you need to ask them
what versions of everything they’re using? It can be a pain and it
usually wastes time/energy, so this is a simple solution.
I wasn’t criticizing. It cracks me up in the sort of "that’s so
obvious, I should do it myself’ sort of way.
On Jan 10, 2008, at 4:11 PM, Nathan S. wrote:
wrote:
wrote:
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
Hop!
James D.
http://devillecompanies.org
[email protected]
rspec r3172
rspec_on_rails r3172
rails r8331
On Thu, 2008-01-10 at 18:09 -0600, David C. wrote:
That all make sense?
In principle, yes. But what if your association isn’t that interesting.
What if it is literally has_many :posts and that’s it. You still want to
make sure it will work (for instance that the posts.blogger_id column
actually exists), but you’ve got nothing interesting to poke it with…
On the other hand maybe it’s stupid testing that as you are really
testing the database, which is a different layer entirely. But in
practise I know it’s quite usual to make a database change and
inadvertently break an association you had forgotten about…
Jon
–
Jonathan L.
http://jonathanleighton.com/
On Thu, 2008-01-10 at 18:47 -0500, Josh K. wrote:
On 1/10/08, Nathan S. [email protected] wrote:
Hmm, that includes a good number of them, but there’s still the
restful resource to think about, which is in my opinion the most
valuable one. Would you consider the addition of a restful resource
matcher similar to shoulda’s?Yes. If you work something up I’d happily add it. Unfortunately I
don’t have the need/time/desire to do it myself right now though.
My reservation with the idea of “should be restful” is that you have to
assume an awful lot about how the controller is implemented. That’s fine
if you use scaffolding excessively but if you actually write your own
code (!!) things quickly start to deviate from the trodden path.
Recently I have been writing my controller specs a bit like this (I have
some support code to enable it):
describe PostsController do
controller_name :posts
stub_resource
describe “when a post is viewed and the current user is an admin” do
log_in :as => :admin
get :show, :id => 42
it_should_find
it_should_load_awesome_admin_stuff
end
describe “when a post is edited by a normal user” do
log_in :as => :prole
get :edit, :id => 23
it_should_find
it_should_warn
it_should_redirect_to "the post's page", :at => "post_path(@post)"
end
end
Some of the above is me using my creative license but you get the idea.
Just thought it might spark some ideas/opinions… it’s certainly not a
perfect implementation/API but I’ve found the general idea quite useful.
I personally think this is the right level at which to make the
abstraction - you are still specifying the behaviour explicitly, just
writing less code when doing it.
Jon
–
Jonathan L.
http://jonathanleighton.com/
On Jan 10, 2008 4:17 PM, Jonathan L. [email protected]
wrote:
In principle, yes. But what if your association isn’t that interesting.
What if it is literally has_many :posts and that’s it. You still want to
make sure it will work (for instance that the posts.blogger_id column
actually exists), but you’ve got nothing interesting to poke it with…
I don’t know. I’m starting to think that this falls under the
category of so simple it’s maybe not worth testing.
Using Rails associations in the simplest way, i.e. no special
conditions, is so declarative that I might consider it to be
specification enough.
I’m not sure though. I’m not totally cool with the idea of trashing
the specs because the code is so expressive that it doesn’t need them.
There’s always something interesting. If there weren’t, it wouldn’t
be in the code to begin with, right? Your example can be something as
simple as
describe Blogger, " who just set up his site" do
it “should have no posts” do
Blogger.new.should have(0).posts
end
end
That at least tells you that there’s a method named #posts, which
responds to length, and has a length of 0 when the blogger is first
instantiated. That’s more behavior-y than specifying the exact
structure of it.
I admit it’s not interesting in the “call the sheriff, pa, there’s
somethin in the barn” sense, but it is interesting in that it’s a
facet of behavior that’s worth knowing.
Pat
You should browse over how shoulda does it here:
and here:
http://dev.thoughtbot.com/shoulda/classes/ThoughtBot/Shoulda/Controller/ClassMethods.html
Nathan S.
[email protected]
rspec 1.1
rspec_on_rails 1.1
rails 2.0.2
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs