# Why detest rspec? (was: community poll about testing and spe

**URL:** <https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241>\
**Category:** Rails\
**Created:** [July 24, 2007, 4:03pm UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241 "2007-07-24T16:03:07Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 24, 2007, 4:03pm UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/1 "2007-07-24T16:03:07Z")

</div>

On 7/24/07, Nathaniel B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> I may be biased, but I would really like and have been looking for an  
> alternative BDD choice besides RSpec.
> 
> What others are there? I have seen a couple by the likes of Ryan, even  
> Rick. Are any better? What about a conrast of testing libraries  
> highlighting the benefits and opinions of each?
> 
> I really want to get into testing beyond Test/Unit, but I detest the  
> RSpec library out of spite 🙂

At the risk of shooting myself in the foot, I’m really curious to know  
why you detest RSpec.

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 24, 2007, 6:16pm UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/2 "2007-07-24T18:16:23Z")

</div>

I didn’t like it for a while because the syntax kept changing. This  
made me rewrite the BDD section of my book twice (three times when I  
rewrite to match 1.0).

But now that I’ve been using the new syntax more, I like it. 😛

–Jeremy

On 7/24/07, David C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> > I really want to get into testing beyond Test/Unit, but I detest the  
> > RSpec library out of spite 🙂
> 
> At the risk of shooting myself in the foot, I’m really curious to know  
> why you detest RSpec.
> 
> >

–  
[http://www.jeremymcanally.com/](http://www.jeremymcanally.com/)

My free Ruby e-book:  
[http://www.humblelittlerubybook.com/book/](http://www.humblelittlerubybook.com/book/)

My blogs:

> **[Site not found · DreamHost](http://www.mrneighborly.com/)**
>
> The owner of this domain has not yet uploaded their website.

[http://www.rubyinpractice.com/](http://www.rubyinpractice.com/)

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 25, 2007, 10:45am UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/3 "2007-07-25T10:45:02Z")

</div>

David C. wrote:

> > I may be biased, but I would really like and have been looking for an  
> > alternative BDD choice besides RSpec.
> > 
> > What others are there? I have seen a couple by the likes of Ryan, even  
> > Rick. Are any better? What about a conrast of testing libraries  
> > highlighting the benefits and opinions of each?
> > 
> > I really want to get into testing beyond Test/Unit, but I detest the  
> > RSpec library out of spite 🙂
> 
> At the risk of shooting myself in the foot, I’m really curious to know  
> why you detest RSpec.

I’d like to chime in. I would not at all say that I detest RSpec in any  
way, but I do find it to be rather besides the point. It just never  
caught on to me, you know?

When I first looked at RSpec, I thought it was rather cryptic. This  
boils down to a matter of taste, I know, but all those “recipes” (I  
don’t know the term) really aren’t all that legible to me.  
“bowling.score.should == 0”? “should” is equal to 0? Is it any more  
expressive than “assert 0, bowling.score”? Again, it’s personal  
preference, but this is one DSL that I don’t care for. So I dismissed it  
in favor of the Test::Units I have come to cherish.

Then I attended a lecture by Aslak Hellesøy. I mean, with so many people  
around raving about RSpec, I must be missing the point right? But I was  
let down: Alsak demonstrated it to be a wrapper DSL around Test::Unit  
for “people who find it hard to come to gripes with TDD”. So it’s a sort  
of workaround? I was disappointed by that statement of his.

He says Test::Unit is tightly coupled to the actual code and that that’s  
a bad thing. I say I like that coupling, because it keeps a sharp edge  
on the test-before-you-write principle: if you’re mucking around code or  
tests that worked before, you’ll find yourself pressed to advocate that  
change and express it in an additional or revised test.

Moving from personal preference into the field of computer science,  
there is no argument that I know of favoring either in code coverage or  
testing metrics. (Indeed, “coupling” and “cohesion” have so far only  
referred to the functional components themselves, not their tests.) This  
doesn’t prove either Alsak or me wrong or right, but does iterate that  
it’s a matter of preference.

“But,” some might say, “we’re testing _behavior_ here. That’s different.  
We can clean up methods, throw code around, but as long as the behavior  
remains the same, then that’s OK.” I see it as the same discussion about  
white box testing and black box testing, but with a twist.

As a black box, the bowling example on the RSpec home page seems to work  
fine. As a white box, it’s lacking in every respect because the  
algorithm we assume to be present is, in fact, completely absent. I like  
to test the algorithm, because if I don’t prove the behavior of the  
algorithm to be correct then I will need to verify every possible  
outcome instead. That kind of verification isn’t very efficient.

So the twist is this: this time around, we’re mixing up black box  
testing by dubbing it “behavior” and white box testing by performing  
actual method calls. I’ve been searching for a rationale, but could only  
find the one by Alsak that I was disappointed by before.

The way I see it, RSpec is just a matter of preference, and a bit of a  
hype at that. Perhaps I’m misunderstanding, and if so, I’d love to see  
the entire mantra clarified. But until then, I’m preferring Test::Unit  
for its readability and code coupling, and saying nay to all those who  
preach that RSpec is a level beyond Test::Unit.

Looking forward to your responses.

–  
Roderick van Domburg

> **[De domeinnaam Nedforce.nl is te koop.](http://www.nedforce.nl)**
>
> Deze mooie domeinnaam kan al over een paar minuten van jou zijn. Betalen gaat eenvoudig en vertrouwd via iDEAL. Direct na de betaling ontvang je de verhuiscode per e-mail en kun je aan de slag.

Perhaps I’m misunderstanding, and if so I’d certainly appreciate it if

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 26, 2007, 12:45am UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/4 "2007-07-26T00:45:46Z")

</div>

@Roderick:  
Wow. That mirrors my thoughts exactly. I’d love for someone to chime in  
and  
counter this. Thanks for putting it so well.

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 26, 2007, 12:46am UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/5 "2007-07-26T00:46:25Z")

</div>

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.

James.

> **[James Mead](https://jamesmead.org/)**
>
> Ruby Developer, author of Mocha, and ex-Antarctic Hero.

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 26, 2007, 12:46am UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/6 "2007-07-26T00:46:20Z")

</div>

> Alsak demonstrated it to be a wrapper DSL around Test::Unit  
> for “people who find it hard to come to gripes with TDD”. So it’s a sort  
> of workaround? I was disappointed by that statement of his.

I don’t get it. What can you write in RSpec that you can’t write,  
nearly the same way, in Test::Unit?

> He says Test::Unit is tightly coupled to the actual code and that that’s  
> a bad thing.

Done right, either one tightly _coheres_ to the actual code.

(Define “couple” as “A must change only because B changed”, and define  
“cohere” as “A and B share legitimate reasons to change together”.)

–  
Phlip  
[http://www.oreilly.com/catalog/9780596510657/](http://www.oreilly.com/catalog/9780596510657/)  
“Test Driven Ajax (on Rails)”  
assert\_xpath, assert\_javascript, & assert\_ajax

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 26, 2007, 12:46am UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/7 "2007-07-26T00:46:27Z")

</div>

On 7/25/07, Roderick van Domburg [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> > > RSpec library out of spite 🙂  
> > > don’t know the term) really aren’t all that legible to me.
> 
> doesn’t prove either Alsak or me wrong or right, but does iterate that  
> to test the algorithm, because if I don’t prove the behavior of the  
> the entire mantra clarified. But until then, I’m preferring Test::Unit  
> for its readability and code coupling, and saying nay to all those who  
> preach that RSpec is a level beyond Test::Unit.

I’m sorry that you see this as preaching and mantras. I have no  
intention of converting you. I like RSpec because it expresses the  
things I want in a BDD framework. You don’t have to like it.

BDD comes from TDD, which comes from XP, which includes Refactoring as  
an integral part of the process. Refactoring is more expensive as your  
tests are more tightly coupled to the code, so one goal of TDD is to  
decouple the tests from the detail of the code (which is what changes  
most often). One thing that aids in this decoupling is focusing on  
behaviour instead of internal implementation. BDD champions this goal  
by putting it front and center. RSpec supports this by trying to use  
words like “describe” instead of “TestCase” and “should” instead of  
“assert.”

It is clear from your arguments that a) your testing goals do not  
align with those of RSpec and b) you’ve only read the cover (your  
argument about the example on the Home Page). If you’re seriously  
interested in learning about RSpec and BDD, then you should try to  
actually use it on a small project and see how it feels. If not, then  
so be it. I still get to use it, so I am happy.

Cheers,  
David

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 26, 2007, 12:47am UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/8 "2007-07-26T00:47:37Z")

</div>

On 7/25/07, Roderick van Domburg [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> in favor of the Test::Units I have come to cherish.  
> Cryptic? Seriously?  
> “bowling score should equal 0”  
> vs  
> “assert 0 bowling score”

The first statement is parseable by a second grader. The second  
statement only makes sense if you are very familiar with test::unit.

I think the problem is that you’re looking at the code and ignoring  
the meaning. You ask “‘should’ is equal to 0?” It seems that you’re  
examining the code the way the interpretter would, and thinking, “the  
object returned by the method should is equal to 0.” That’s  
completely the wrong mindset.

I would say that TDD is a tool to help you solve the problem of  
designing and implementing behavior. Test::Unit works fine in that  
regard, but RSpec reduces the semantic distance between the developer  
and the problem domain.

Consider a task list you write for yourself. Again you’ll have  
statements that look like “bowling score should equal 0” rather than  
“assert 0 bowling score.” Throw in a couple dots and you’re good to  
go 🙂 RSpec lets you express behavior in code almost as neatly as you  
do in your head. That’s very, very powerful. I’ve yet to come across  
a tool that brings you that close.

> Then I attended a lecture by Aslak Hellesøy. I mean, with so many people  
> around raving about RSpec, I must be missing the point right? But I was  
> let down: Alsak demonstrated it to be a wrapper DSL around Test::Unit  
> for “people who find it hard to come to gripes with TDD”. So it’s a sort  
> of workaround? I was disappointed by that statement of his.

I’m not sure how long ago that lecture was, but to the best of my  
knowledge RSpec is no longer just a wrapper around Test::Unit. On the  
other hand, I’m not sure why it matters how it’s implemented under the  
hood. We are concerned with behavior here, after all 😉

Anyway, the big BDD guys all basically say that there’s nothing  
different if you’re doing TDD right. BDD/RSpec isn’t a workaround to  
TDD, but rather a fast track to the good things about TDD. Again you  
have the benefit of a shorter semantic distance. By using RSpec you  
start off focusing on design and behavior, which is the ultimate goal  
of TDD.

> He says Test::Unit is tightly coupled to the actual code and that that’s  
> a bad thing. I say I like that coupling, because it keeps a sharp edge  
> on the test-before-you-write principle: if you’re mucking around code or  
> tests that worked before, you’ll find yourself pressed to advocate that  
> change and express it in an additional or revised test.

The concern is that Test::Unit encourages an artificial coupling of  
one test class to one production class. That’s a completely different  
thing from tests being coupled to the code, which as you pointed out  
will/should be the case. The problem is that a new test class can  
feel heavy weight (especially if you’ve been using JUnit for several  
years, you almost certainly have that stigma). People think, “wow why  
should I create a whole new class when it’s just a little bit of  
behavior?” Most people know that it’s not a good idea to have a class  
with just one or two methods, but testing has different rules and the  
fact is that a test class with just a few methods is often precisely  
what you need.

RSpec helps you avoid this problem by encouraging you to write several  
small, focused examples. Once again it’s not something that you  
couldn’t do with Test::Unit, but the RSpec way is just a lot closer to  
the Right Way.

> white box testing and black box testing, but with a twist.
> 
> As a black box, the bowling example on the RSpec home page seems to work  
> fine. As a white box, it’s lacking in every respect because the  
> algorithm we assume to be present is, in fact, completely absent. I like  
> to test the algorithm, because if I don’t prove the behavior of the  
> algorithm to be correct then I will need to verify every possible  
> outcome instead. That kind of verification isn’t very efficient.

I don’t think RSpec is meant to be a white-box testing tool. Again,  
it’s all about design and behavior. Despite that, you should still be  
able to achieve a sufficient level of white-box testing using mocks.

In fact, sometimes I’ll write two sets of specs for the same example.  
One will use concrete implementations, allowing me to verify that I  
get the desired side-effects (records created, etc). Another one will  
use mocks, allowing me to verify that the proper interactions are  
being made. I’ve got a good example, but I don’t want to add 65 lines  
of code to this already lengthy message…but if there’s any interest  
I’ll be happy to post it in a followup message.

> So the twist is this: this time around, we’re mixing up black box  
> testing by dubbing it “behavior” and white box testing by performing  
> actual method calls. I’ve been searching for a rationale, but could only  
> find the one by Alsak that I was disappointed by before.
> 
> The way I see it, RSpec is just a matter of preference, and a bit of a  
> hype at that. Perhaps I’m misunderstanding, and if so, I’d love to see  
> the entire mantra clarified. But until then, I’m preferring Test::Unit  
> for its readability and code coupling, and saying nay to all those who  
> preach that RSpec is a level beyond Test::Unit.

Sure, just as some people prefer C. It’s certainly more readable -  
you have semicolons that tell you where a statement ends!

Pat

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 26, 2007, 10:08am UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/9 "2007-07-26T10:08:15Z")

</div>

Thanks for your replies everyone – it sure has been improving my  
understanding, plus I love the debate. 🙂

Allow me to respond chronologically.

Phlip wrote:

> > Alsak demonstrated it to be a wrapper DSL around Test::Unit  
> > for “people who find it hard to come to gripes with TDD”. So it’s a sort  
> > of workaround? I was disappointed by that statement of his.
> 
> I don’t get it. What can you write in RSpec that you can’t write,  
> nearly the same way, in Test::Unit?

That was exactly my point.

Phlip wrote:

> > He says Test::Unit is tightly coupled to the actual code and that that’s  
> > a bad thing.
> 
> Done right, either one tightly _coheres_ to the actual code.
> 
> (Define “couple” as “A must change only because B changed”, and define  
> “cohere” as “A and B share legitimate reasons to change together”.)

That was me quoting him. Both Alsak and you are right. 🙂

Alsak is right in the sense that tight coupling indeed does not improve  
testability or robustness because a network of modules that are  
interrelated are more difficult to test than modules in isolation.

I totally agree with you on the cohesion tab. Cohesion (singleness of  
purposeness of a module) is generally regarded as a good thing to have  
in computer science and is indicative of a well-designed software  
architecture that is reusable and understandable.

In fact, it is often said that a high cohesion correlates with high test  
coverage, because a single test will touch on multiple facets of the  
module, and hence multiple tests will cover the facets multiple times.

But here’s the thing: these quality measures are about intra- or  
inter-relationships between functional modules – not between a  
functional module and its unit tests. When we speak in this context of  
modules and their unit tests, I have yet to find any evidence that  
either refer cohesion or coupling is either desirable or undesirable.

The point I’m trying to make here is this: with “tight coupling” [sic.]  
being listed as one of the reasons to move away from Test::Unit, that  
really just is preference over fact.

James M. 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.

I apologize for my misquoting. It is not my intention to bring either  
discredit or misuse their words.

David C. wrote:

> I’m sorry that you see this as preaching and mantras. I have no  
> intention of converting you. I like RSpec because it expresses the  
> things I want in a BDD framework. You don’t have to like it.

But maybe I don’t know what I’m missing, in which case I want to like  
it! 🙂

David C. wrote:

> BDD comes from TDD, which comes from XP, which includes Refactoring as  
> an integral part of the process. Refactoring is more expensive as your  
> tests are more tightly coupled to the code, so one goal of TDD is to  
> decouple the tests from the detail of the code (which is what changes  
> most often). One thing that aids in this decoupling is focusing on  
> behaviour instead of internal implementation. BDD champions this goal  
> by putting it front and center. RSpec supports this by trying to use  
> words like “describe” instead of “TestCase” and “should” instead of  
> “assert.”

I do acknowledge the design goals, but keep wondering: how can only  
words make the difference between BDD and TDD? I fail to see how  
replacing words and reshuffling parameters (i.e. assert 0, bowling.score  
 → bowling.score.should == 0) can facilitate the decoupling / decrease  
in cohesion.

David C. wrote:

> It is clear from your arguments that a) your testing goals do not  
> align with those of RSpec and b) you’ve only read the cover (your  
> argument about the example on the Home Page). If you’re seriously  
> interested in learning about RSpec and BDD, then you should try to  
> actually use it on a small project and see how it feels. If not, then  
> so be it. I still get to use it, so I am happy.

You are absolutely right in this. I should truly give it a whirl and  
haven’t yet. I only checked out the examples and attended Alsak’s 2007  
lecture. Not trying sure is bad developer practice 🙂 Thanks for point  
that out to me, it’s a good reality check.

Could you tell me though, what is the gap that you perceive between my  
testing goals and those of RSpec? That knowledge would be really helpful  
in completing my mental picture about RSpec.

Pat M. wrote:

> On 7/25/07, Roderick van Domburg [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> wrote:
> 
> > in favor of the Test::Units I have come to cherish.  
> > Cryptic? Seriously?  
> > “bowling score should equal 0”  
> > vs  
> > “assert 0 bowling score”

Again, thanks! I was reading aloud: “bowling score should is equal to  
0”. Never thought of keeping it simpler than that.

Pat M. wrote:

> > Then I attended a lecture by Aslak Helles�y. I mean, with so many people  
> > around raving about RSpec, I must be missing the point right? But I was  
> > let down: Alsak demonstrated it to be a wrapper DSL around Test::Unit  
> > for “people who find it hard to come to gripes with TDD”. So it’s a sort  
> > of workaround? I was disappointed by that statement of his.
> 
> I’m not sure how long ago that lecture was, but to the best of my  
> knowledge RSpec is no longer just a wrapper around Test::Unit. On the  
> other hand, I’m not sure why it matters how it’s implemented under the  
> hood. We are concerned with behavior here, after all 😉

Indeed that was my perception of things, not something he said.

Earlier Philip asked “I don’t get it. What can you write in RSpec that  
you can’t write, nearly the same way, in Test::Unit?”. That’s the same  
flow of mind that got me to arrive to this perception.

Pat M. wrote:

> > He says Test::Unit is tightly coupled to the actual code and that that’s  
> > a bad thing. I say I like that coupling, because it keeps a sharp edge  
> > on the test-before-you-write principle: if you’re mucking around code or  
> > tests that worked before, you’ll find yourself pressed to advocate that  
> > change and express it in an additional or revised test.
> 
> The concern is that Test::Unit encourages an artificial coupling of  
> one test class to one production class. That’s a completely different  
> thing from tests being coupled to the code, which as you pointed out  
> will/should be the case. The problem is that a new test class can  
> feel heavy weight (especially if you’ve been using JUnit for several  
> years, you almost certainly have that stigma). People think, “wow why  
> should I create a whole new class when it’s just a little bit of  
> behavior?” Most people know that it’s not a good idea to have a class  
> with just one or two methods, but testing has different rules and the  
> fact is that a test class with just a few methods is often precisely  
> what you need.
> 
> RSpec helps you avoid this problem by encouraging you to write several  
> small, focused examples. Once again it’s not something that you  
> couldn’t do with Test::Unit, but the RSpec way is just a lot closer to  
> the Right Way.

That did put things into perspective for me. Thanks!

Pat M. wrote:

> > As a black box, the bowling example on the RSpec home page seems to work  
> > fine. As a white box, it’s lacking in every respect because the  
> > algorithm we assume to be present is, in fact, completely absent. I like  
> > to test the algorithm, because if I don’t prove the behavior of the  
> > algorithm to be correct then I will need to verify every possible  
> > outcome instead. That kind of verification isn’t very efficient.
> 
> I don’t think RSpec is meant to be a white-box testing tool. Again,  
> it’s all about design and behavior. Despite that, you should still be  
> able to achieve a sufficient level of white-box testing using mocks.
> 
> In fact, sometimes I’ll write two sets of specs for the same example.  
> One will use concrete implementations, allowing me to verify that I  
> get the desired side-effects (records created, etc). Another one will  
> use mocks, allowing me to verify that the proper interactions are  
> being made. I’ve got a good example, but I don’t want to add 65 lines  
> of code to this already lengthy message…but if there’s any interest  
> I’ll be happy to post it in a followup message.

I am interested! I enjoy the discussion and think it’ll be 65 lines well  
spent. 🙂

Cheers,

Roderick

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 26, 2007, 11:11am UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/10 "2007-07-26T11:11:07Z")

</div>

On 7/26/07, Jacob A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> This sounds very interesting. I would love to see a concrete example  
> detailing your approach.

Okay, here we go 🙂

describe VideoService, " when creating a video" do  
fixtures :companies, :sites, :video\_formats, :publish\_settings

before(:each) do  
@video = Video.new  
@video.company = companies(:test)  
@video.site = sites(:test)  
sites(:test).stub!(:formats).and\_return [video\_formats(:flash)]

```
@origin = mock_model(Origin, :process_source => true,

```

:transcode\_asset =\> true, :storage =\> “file”)  
Origin.stub!(:find\_transcoder).and\_return @origin

```
@service = VideoService.new

```

end

def create\_video  
@service.create\_video :video =\> @video, :signature =\> “abc123”,  
:frame =\> 1, :storage =\> “file”  
end

it “should add a new video record” do  
lambda { create\_video }.should change(Video, :count).by(1)  
end

it “should create two assets - one source and one transcoded” do  
lambda { create\_video }.should change(Asset, :count).by(2)  
@video.source\_asset.should be\_source  
@video.should have(2).assets  
end

it “should create the main asset with the appropriate video format” do  
create\_video  
@video.assets.find\_by\_video\_format\_id(video\_formats(:flash).id).should\_not  
be\_blank  
end  
end

describe VideoService, " when creating a video" do  
fixtures :companies, :sites, :video\_formats

before(:each) do  
@video = mock\_model(Video, :save =\> true, :company\_id =\>  
companies(:test).id, :site =\> sites(:test), :hook =\> nil)  
sites(:test).stub!(:formats).and\_return [video\_formats(:flash)]

```
@source_asset = mock_model(Asset, :video_id= => @video.id, :save => 

```

true)  
@transcode\_asset = mock\_model(Asset, :video\_id= =\> @video.id, :save  
=\> true)  
Asset.stub!(:new).and\_return @source\_asset, @transcode\_asset  
@video.stub!(:source\_asset).and\_return @source\_asset

```
@source_origin = mock_model(Origin, :process_source => true,

```

:transcode\_asset =\> true, :storage =\> “file”)  
@transcode\_origin = mock\_model(Origin, :transcode\_asset =\> true,  
:storage =\> “file”)  
Origin.stub!(:find\_transcoder).and\_return @source\_origin,  
@transcode\_origin

```
@service = VideoService.new

```

end

def create\_video  
@service.create\_video :video =\> @video, :signature =\> “abc123”,  
:frame =\> 1, :storage =\> “file”  
end

it “should find a transcoder” do  
Origin.should\_receive(:find\_transcoder).with(companies(:test).id,  
false, “file”).and\_return @source\_origin  
create\_video  
end

it “should process the source asset” do  
@source\_origin.should\_receive(:process\_source).with(“abc123”,  
@source\_asset, 1, “[http://test.host:80/](http://test.host:80/)”)  
create\_video  
end

it “should find an origin for the transcode format” do  
Origin.should\_receive(:find\_transcoder).with(companies(:test).id,  
false, nil).and\_return @transcode\_origin  
create\_video  
end

it “should transcode the new asset” do  
@transcode\_origin.should\_receive(:transcode\_asset).with(“abc123”,  
@transcode\_asset, “[http://test.host:80/](http://test.host:80/)”,  
“[http://test.host:80/video\_formats/#{video\_formats(:flash).id}.xml](http://test.host:80/video_formats/#%7Bvideo_formats(:flash).id%7D.xml)”)  
create\_video  
end  
end

I created the VideoService to wrap the creation of a video in our  
system. At that stage in the code, there were a couple main parts -  
creating a new video record, creating a couple asset records, and  
notifying our transcode machines about the new assets.

The first example specifies the db behavior I want. That was my  
black-box test (you might say it’s grey-box because I’m stubbing some  
stuff out, but that wasn’t part of the original spec. It’s just there  
so the spec can run - Origin makes a network call and it’s easier to  
stub the whole thing out).

The second example is the white-box test, which verifies that the  
internals work. Certain origins should be found, they need to receive  
certain calls with a particular video, etc.

Now I’m not sure if people will like those specs 🙂 but hopefully it  
gives you an idea of how you can approach specifications from both  
angles.

Pat

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 26, 2007, 4:09pm UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/11 "2007-07-26T16:09:47Z")

</div>

On 7/26/07, Roderick van Domburg [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> Could you tell me though, what is the gap that you perceive between my  
> testing goals and those of RSpec? That knowledge would be really helpful  
> in completing my mental picture about RSpec.

My perception is based on your statement that you find the tight  
coupling between tests and the subject code to be a good thing, and  
that you like the fact that making changes to code forces you to make  
changes to your tests.

Compare this to TDD’s goal of supporting inexpensive refactoring  
through very loose coupling between tests and code.

I also sensed that you don’t find value in focusing the discussion on  
behaviour:

# ============================================= “But,” some might say, “we’re testing _behavior_ here.”

To me, putting the focus on behaviour encourages a subtle, yet  
powerful change in how you perceive these things we call  
tests/specs/examples, etc. Obviously, RSpec is interested in helping  
you to think of tests as executable examples of expected behaviour as  
opposed to, well, tests.

This help?

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 26, 2007, 5:10pm UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/12 "2007-07-26T17:10:37Z")

</div>

David C. wrote:

> To me, putting the focus on behaviour encourages a subtle, yet  
> powerful change in how you perceive these things we call  
> tests/specs/examples, etc. Obviously, RSpec is interested in helping  
> you to think of tests as executable examples of expected behaviour as  
> opposed to, well, tests.
> 
> This help?

Yes, that is a metaphor that sticks.

All that rests now is how “renaming” assert(x, y) to Object#should truly  
facilitates that idea. Yes there are other niceties and syntactic sugar,  
but isn’t providing a humanized DSL really the gist of it all?

In the end, you’ll still be comparing method results and variable  
assignments.

–  
Roderick van Domburg

> **[De domeinnaam Nedforce.nl is te koop.](http://www.nedforce.nl)**
>
> Deze mooie domeinnaam kan al over een paar minuten van jou zijn. Betalen gaat eenvoudig en vertrouwd via iDEAL. Direct na de betaling ontvang je de verhuiscode per e-mail en kun je aan de slag.

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 26, 2007, 10:08am UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/13 "2007-07-26T10:08:44Z")

</div>

Pat M. wrote:

> In fact, sometimes I’ll write two sets of specs for the same example.  
> One will use concrete implementations, allowing me to verify that I  
> get the desired side-effects (records created, etc). Another one will  
> use mocks, allowing me to verify that the proper interactions are  
> being made. I’ve got a good example, but I don’t want to add 65 lines  
> of code to this already lengthy message…but if there’s any interest  
> I’ll be happy to post it in a followup message.

This sounds very interesting. I would love to see a concrete example  
detailing your approach.

–  
Cheers,

- Jacob A.

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 27, 2007, 8:49am UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/14 "2007-07-27T08:49:19Z")

</div>

Roderick van Domburg wrote:

> All that rests now is how “renaming” assert(x, y) to Object#should truly  
> facilitates that idea. Yes there are other niceties and syntactic sugar,  
> but isn’t providing a humanized DSL really the gist of it all?
> 
> In the end, you’ll still be comparing method results and variable  
> assignments.

Yes, in the end… you see a result like this. But, I’d like to back  
this up to before you write your code.

Let’s start with a high-level business rule for an application. We might  
have a discussion with our client and determine the following.

A user should not be allowed to create a new account when providing an  
existing email address.

This is something that we’d have our clients agree upon before we ever  
touched any code. When it comes time to implement this behavior into the  
application, we can translate this into RSpec very easily.

describe User, “new account” do

it “should not be allowed to create a new account when providing an  
existing email address.”

end

When we run our specs, this will show up as unimplemented. I often add  
several of these once a client has signed off on some specifications,  
and it results in a TODO-list for me. At this point, I can begin turning  
these into full specs.

In a nuthsell, it’s not just a DSL for Ruby… it’s provides a framework  
for discussing requirements with our clients and Interaction Design  
team. It’s clear English and leaves little room for ambiguity, which I  
believe is a good thing! 🙂

If you enjoy translating high-level requirements into Test::Unit… and  
don’t mind the underscore/camelcase madeness… well, good luck with  
that. I switched to Ruby/Rails because of how expressive and  
English-like it was and think that it’s very fitting that RSpec would  
evolve out of this community.

Cheers,  
Robby

–  
Robby R.  
[http://www.robbyonrails.com/](http://www.robbyonrails.com/)

> **[Planet Argon](https://www.planetargon.com/)**
>
> Planet Argon is a Ruby on Rails development agency specializing in maintenance and support for existing Rails apps. Based in Portland, OR, Planet Argon has been a member of the Rails community since 2004.

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 27, 2007, 11:58am UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/15 "2007-07-27T11:58:36Z")

</div>

Hi –

On Thu, 26 Jul 2007, Robby R. wrote:

> When we run our specs, this will show up as unimplemented. I often add  
> don’t mind the underscore/camelcase madeness… well, good luck with  
> that. I switched to Ruby/Rails because of how expressive and  
> English-like it was and think that it’s very fitting that RSpec would  
> evolve out of this community.

OK… but, lest we forget, Nathaniel’s work on test/unit – past,  
present, and future (I hope) – has played an incalculable role in  
shaping the Ruby programming culture. Luckily, it’s not a zero-sum  
game; people can delve into RSpec without having to jettison or scoff  
at test/unit. It’s possible for two highly-accomplished test  
frameworks to evolve out of the same community 🙂

(I’m not trying to get you to like test/unit; I’m just putting in a  
word for not having it have to be a winner-take-all kind of  
relationship, and also eager to keep the significance of test/unit to  
Ruby culture on the radar. I know I’m showing my age – in this case,  
almost seven 🙂

David

–

- Books:  
RAILS ROUTING (new! [http://www.awprofessional.com/title/0321509242](http://www.awprofessional.com/title/0321509242))  
RUBY FOR RAILS ([Ruby for Rails](http://www.manning.com/black))
- Ruby/Rails training  
& consulting: Ruby Power and Light, LLC ([http://www.rubypal.com](http://www.rubypal.com))

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 27, 2007, 3:32pm UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/16 "2007-07-27T15:32:58Z")

</div>

On 7/27/07, removed\_email\_address@domain.invalid [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> > for discussing requirements with our clients and Interaction Design  
> > present, and future (I hope) – has played an incalculable role in  
> > shaping the Ruby programming culture. Luckily, it’s not a zero-sum  
> > game; people can delve into RSpec without having to jettison or scoff  
> > at test/unit. It’s possible for two highly-accomplished test  
> > frameworks to evolve out of the same community 🙂

More than two. Don’t forget watir. And all of the mocking frameworks.  
There’s a lot of good stuff here.

> (I’m not trying to get you to like test/unit; I’m just putting in a  
> word for not having it have to be a winner-take-all kind of  
> relationship, and also eager to keep the significance of test/unit to  
> Ruby culture on the radar.

A very important point. And now that Ryan has taken over maintenance  
of test/unit, I expect to see some great new ideas appearing there as  
well.

The thing about RSpec is that it is intended to be a BDD framework,  
not a testing framework. It aims to support a behaviour-focused  
process in which you, in very granular steps, describe a bit of  
behaviour and then implement it.

But BDD is not the end of the testing story on any project. At least I  
don’t think it _should_ be. Some might even say it’s not part of the  
testing story at all 🙂

A perfect example is Matrix Testing, introduced by ZenTest. In  
fairness, I haven’t done this yet, but I can imagine a process that  
goes like this:

1. Develop a component using TDD (and RSpec) to encourage simple  
design and usable APIs.
2. Write a matrix test (using ZenTest with test/unit) to ensure that  
you’ve covered all of the permutations you anticipate.
3. If the matrix test exposes any holes, go back and use RSpec to  
drive the process of plugging them.

I can hear some saying “but that’s doing the same work twice. Why not  
just a Matrix Test to begin with and call it a day?”

Because these two tools/approaches solve different problems. RSpec/BDD  
is good at expressing behaviour and encouraging simple, flexible  
designs. MatrixTesting is good at expressing multiple permutations in  
a clean and simple way. Used together, I believe that you’d end up  
with a simpler design with better test coverage than you would with  
either tool alone.

In XP we do Customer Tests and Developer Tests, though these have a  
lot of different names. They are, in the end, exercising the same  
code. But they express very different things. And what my experience  
tells me is that it’s the combination of layers of testing that proves  
most effective. So for me, this notion of combining a BDD framework  
(for DESIGN) with a testing framework (for TESTING) makes perfect  
sense.

> I know I’m showing my age – in this case,  
> almost seven 🙂

Happy Birthday (6 year olds only say “almost 7” when it’s just a few  
days away).

Cheers,  
David

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 29, 2007, 1:47pm UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/17 "2007-07-29T13:47:29Z")

</div>

Many thanks for taking the time to write down your thoughts, everyone.  
It’s been very helpful to me to put RSpec in perspective. I’ll take it  
for a whirl like David suggested, and will revisit this topic if RSpec  
manages to win me over. 🙂

–  
Roderick van Domburg

> **[De domeinnaam Nedforce.nl is te koop.](http://www.nedforce.nl)**
>
> Deze mooie domeinnaam kan al over een paar minuten van jou zijn. Betalen gaat eenvoudig en vertrouwd via iDEAL. Direct na de betaling ontvang je de verhuiscode per e-mail en kun je aan de slag.

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [September 25, 2007, 11:03pm UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/18 "2007-09-25T23:03:30Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [July 27, 2007, 2:52pm UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/19 "2007-07-27T14:52:53Z")

</div>

On 7/26/07, Roderick van Domburg [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> All that rests now is how “renaming” assert(x, y) to Object#should truly  
> facilitates that idea.

I think this is one of several aspects of RSpec that help promote this  
idea. I do thing that saying “should” instead of “assert” changes the  
feel from tests to examples of behaviour. But it’s not limited to  
that.

The structure/organization using describe/it instead of  
TestCase/test\_method and, especially, using strings to express the  
intent rather than method names both go a long way to support this  
shift in focus. The reporting you get helps as well.

David

---

<div class="post-metadata">

**Author:** ![crucoba](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@crucoba](https://www.ruby-forum.com/u/crucoba)\
**Post date:** [September 25, 2007, 11:03pm UTC](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241/20 "2007-09-25T23:03:56Z")

</div>

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:

[http://www.faqs.org/rfcs/rfc2119.html](http://www.faqs.org/rfcs/rfc2119.html)

-faisal

[Next page](https://www.ruby-forum.com/t/why-detest-rspec-was-community-poll-about-testing-and-spe/110241.md?page=2)