s.ross wrote:
This argument is the same one you could use to say “what can you write in
Ruby that you can’t write, nearly the same way, in C”?
Uh, in the same volume of code? At the same velocity?
–
Phlip
http://www.oreilly.com/catalog/9780596510657/
^ assert_xpath
O'Reilly Media - Technology and Business Training ← assert_raise_message
We could debate either side of the issue. I could say “with the same
compactness? with equivalent performance characteristics?” but at the
end of the discussion, it’s all about what clicks for you. If you are
happy with asserts (like in C, hence my analogy), then use them. I
believe the BDD people – and I count David among one of the most
thoughtful of the bunch – have put a good deal of work into making
the description of the spec as natural as possible. Again, it’s what
reads naturally to you. If you don’t parse it naturally, then no
prob. Also, make careful note of what David says about the failure
messages. This was one of my biggest complaints with Test::Unit and
the fix is pretty close to free with RSpec. The failures report
pretty much in English and if they don’t I probably wrote the example
wrong.
–s
On 7/25/07, Faisal N Jawdat [email protected] wrote:
On Jul 25, 2007, at 11:50 AM, David C. wrote:
RSpec supports this by trying to use words like “describe” instead
of “TestCase” and “should” instead of “assert.”As an aside, RSpec’s use of “should” may be confusing to anyone
coming from the networking world:RFC 2119 - Key words for use in RFCs to Indicate Requirement Lev (RFC2119)
Can’t clarify everything for everybody I guess.
On 7/25/07, Phlip [email protected] wrote:
s.ross wrote:
This argument is the same one you could use to say “what can you write in
Ruby that you can’t write, nearly the same way, in C”?Uh, in the same volume of code? At the same velocity?
OK, so what about python?
I think the point Steve was making was about “feel”, which is what
Ruby and Rails are largely about. To me, there is a huge difference
between this:
team.should have(11).players
and this
assert_equal 11, team.players.size
And an even bigger difference in the output when these fail:
expected 11 players, got 10
vs
expected 11, got 10
Implementing these probably takes the same amount of time. A month
later, seeing “expected 11 players” is VERY meaningful, especially
when multiple failures appear due to a change you just made. If I see
10 failures that all say “expected x things, got y”, then I have a lot
more information right away about what went wrong than if I just see
“expected x, got y”.
FWIW.
David
Hi –
On Wed, 25 Jul 2007, Faisal N Jawdat wrote:
On Jul 25, 2007, at 11:50 AM, David C. wrote:
RSpec supports this by trying to use words like “describe” instead
of “TestCase” and “should” instead of “assert.”As an aside, RSpec’s use of “should” may be confusing to anyone
coming from the networking world:RFC 2119 - Key words for use in RFCs to Indicate Requirement Lev (RFC2119)
I don’t think that coming from the networking world means one can’t
make the leap of imagination required to realize that the entire world
does not speak in compliance with RFC2119 
I wouldn’t worry about
it for a second.
David
–
On 7/25/07, James M. [email protected] wrote:
Roderick: David C. might be a little miffed with your selective
quoting which makes it appear as if he doesn’t like RSpec…David C. wrote:
I may be biased, but I would really like and have been looking for an
alternative BDD choice besides RSpec.This was not written by David, but was written in response to an email from
him. The only clue to this is the level of indentation of the quoting.
Actually, this makes me laugh more than piss me off. But thanks for
sticking up for me
Cheers,
David
On Jul 25, 6:34 pm, Faisal N Jawdat [email protected] wrote:
On Jul 25, 2007, at 11:50 AM, David C. wrote:
RSpec supports this by trying to use words like “describe” instead
of “TestCase” and “should” instead of “assert.”As an aside, RSpec’s use of “should” may be confusing to anyone
coming from the networking world:RFC 2119 - Key words for use in RFCs to Indicate Requirement Lev (RFC2119)
Fortunately, if you find “should” confusing or misleading you can
write your examples such as this one:
it “should redirect to the home page after logging out”
like this instead:
it “must redirect to the home page after logging out”
Or using any other word or language you think is better. The language
you employ in your examples is up to you, although the RSpec community
does tend to use some widespread patterns, including the use of the
word “should” in a way that is closer to the “standard English sense”
rather than the “RFC-2119 sense”.
Cheers,
Wincent
Would you be kind enough to briefly explain what you perceive to be the
advantages to RSpec? I’m really hoping for a good comparison of the two,
so
I can see if it’s worth investigating further. (I am writing a book that
will include testing, and need more info). I’ve played with RSPec and
haven’t really found anything I can’t do with test:unit… so that’s
why
I’m looking for more info. I’d really appreciate some input. I suspect
that
it’s much like TDD… you have to do it before you really appreciate it.
s.ross wrote:
This argument is the same one you could use to say “what can you write
in Ruby that you can’t write, nearly the same way, in C”? Heck, they are
both TC general purpose computer programming languages. Ahhhh, but the
“feel” is different. That’s what I find sets RSpec apart, and if it
doesn’t click for you it might not work for you.
Agreed. I also consider RSpec to be one of those most exciting things to
pop up in the Ruby community since Rails. Our pure-Ruby libs are being
spec’d (not tested) and we can pretty much run rm -rf test/ in our Rails
applications.
It might not sit well with all, but the syntax is a great example of how
great and expressive Ruby can be.
Robby
–
Robby R.
http://www.robbyonrails.com/
On 7/26/07, Wincent C. [email protected] wrote:
RFC 2119 - Key words for use in RFCs to Indicate Requirement Lev (RFC2119)
Or using any other word or language you think is better. The language
you employ in your examples is up to you, although the RSpec community
does tend to use some widespread patterns, including the use of the
word “should” in a way that is closer to the “standard English sense”
rather than the “RFC-2119 sense”.Cheers,
Wincent
I’m pretty sure that he’s referring to
foo.should == bar
However I have to say I think it’s an absurdly nitty “issue”
Pat
On 7/25/07, Brian H. [email protected] wrote:
Would you be kind enough to briefly explain what you perceive to be the
advantages to RSpec? I’m really hoping for a good comparison of the two, so
I can see if it’s worth investigating further. (I am writing a book that
will include testing, and need more info). I’ve played with RSPec and
haven’t really found anything I can’t do with test:unit… so that’s why
I’m looking for more info. I’d really appreciate some input. I suspect that
it’s much like TDD… you have to do it before you really appreciate it.
I don’t know that there is anything that you can’t do with test/unit -
just that rspec comes w/ a lot of this stuff out of the box. And I
think it is something experiential. Many people who really enjoy using
RSpec say they were skeptical at first, but have grown to love it.
Here are some specific comparisons:
describe Thing do
it “should do cool stuff” do
…
end
end
vs
class ThingTest << Test::Unit::TestCase
def test_should_do_cool_stuff
…
end
end
I find that this encourages better naming and organization.
team.should have(11).players
vs
assert_equal 11, team.players.size
expected empty? to return true, got false
vs
expected true, got false
Thing
vs
…
There is also a nicely formatted HTML report out of the box:
http://rspec.rubyforge.org/report.html
I’m sure there’s more that I’m not thinking of right now. There’s also
the “joy” factor. I find it a more joyful experience to use RSpec, for
the reasons stated above and for reasons that you can only appreciate
by exploring it.
Hope this helps.
Cheers,
David
Pat M. wrote:
foo.should == bar
Ah, yes, you’re almost certainly right.
Well the solution to that is also only a step away (alias “should” and
“should_not” to whatever you want in your spec helper file). Of
course, I wouldn’t actually recommend doing so, as it seems to be
going against the grain for no real good reason.
Cheers,
Wincent
Great stuff. If you were going to expose people to tests, would you
start
with TDD and test:unit, or would you go right to BDD and RSpec?
Brian H. wrote:
Would you be kind enough to briefly explain what you perceive to be the
advantages to RSpec? I’m really hoping for a good comparison of the two, so
I can see if it’s worth investigating further. (I am writing a book that
will include testing, and need more info). I’ve played with RSPec and
haven’t really found anything I can’t do with test:unit…
And that’s as expected. As you’ll read in most intros to BDD, it’s the
same practice as TDD, but with the focus shifted. Everything you can do
with BDD can be done with TDD.
People seem to be expecting some sort of sea change in development
practices, but that’s not going to happen here. And from what I’ve read,
it was never intended to.
It’s a small tweak, to refocus TDD practitioners a slight bit. They
think it produces better specs/tests, not because it’s something that
couldn’t be done before, but because it’s now more obvious what you
should be doing.
If TDD has always worked well for you (as I’ve read before, “if you’ve
been doing it right all along”), then great, stick with it.
But the very simple terminology changes are what made the point of TDD
finally click for me.
As for rspec specifically? It does what I need it to, produces
phenomenally legible specs, and then stays out of the way.
Kyle
…
I first saw RSpec in one of the tutorials at RailsConf this year. The
positive reinforcement from seeing what you were testing each time was
compelling. I also find seeing the list of tested behaviors often
suggests to me the next test/feature that needs to be added to the
project. (Now if I could just get my rspec.conf file to be used so I
don’t have to pass ‘-f specdoc’ each time I run my tests.
- rspec_on_rails - component isolation allows you to test views before
controllers or models even exist. This is VERY helpful when you’re on
an XP or XP-like team.
David, could you expand on this? Or post a link to docs or a tutorial
or blog post about testing views with RSpec.
–
Cynthia K.
[email protected]
On 7/27/07, Cynthia K. [email protected] wrote:
David C. wrote:
- rspec_on_rails - component isolation allows you to test views before
controllers or models even exist. This is VERY helpful when you’re on
an XP or XP-like team.David, could you expand on this? Or post a link to docs or a tutorial
or blog post about testing views with RSpec.
http://blog.davidchelimsky.net/articles/2006/11/06/view-spec-tutorial
http://rspec.rubyforge.org/documentation/rails/writing/views.html
http://rspec.rubyforge.org/rdoc-rails/index.html
Cheers,
David
On 7/25/07, Brian H. [email protected] wrote:
Great stuff. If you were going to expose people to tests, would you start
with TDD and test:unit, or would you go right to BDD and RSpec?
Green field? i.e. no experience with testing at all? Definitely RSpec.
Beyond that, it depends on myriad factors, mostly boiling down to what
is going to be most pragmatic for the team based on their level of
experience with Ruby, testing in general, other frameworks, etc. I’d
always prefer RSpec because, well, I prefer it. But sometimes going w/
test/unit could be more pragmatic, at least in the short run.
David
Look here:
http://rspec.rubyforge.org/documentation/rails/writing/views.html
The idea is that you can mock enough to populate the view data
allowing you to design from the “outside in.” Basically mock up your
UI, do it in RHTML (or whatever markup you like), and write specs for
that.
Brian H. wrote:
Great stuff. If you were going to expose people to tests, would you
start with TDD and test:unit, or would you go right to BDD and RSpec?
Our team adopted RSpec about a year ago and we’ve been through several
projects entirely without Test::Unit. If someone has never had any
experience with TDD, then I would advocate learning through BDD… and
would recommend RSpec as the framework to learn it with.
On a side note. JRuby 1.0 will come with two gems.
Rake and RSpec.
Yes… people are using it in the real world and I can testify on it’s
behalf in court. It’s elegant. Our developers LOVE it. I love it. Even
our Interaction Designers have picked up on the lingo and use
“should”-style language in their interface specifications, which
translates nicely into our implementation process.
RSpec ftw!
Robby
–
Robby R.
http://www.robbyonrails.com/
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