Asp Forum - I don't get rspec

nicknameoptional

1/19/2007 9:37:00 PM

I just discovered rspec today, reading the example and tutorials,
besides the doc and coverage features, I can't see how is it different
from unit test. For my rails app, existing testing tools in rails
already fills all my testing needs. So what does rspec do more than
existing testing tools? Thanks.

http://rspec.rubyforge.org/tools/...

47 Answers

James Britt

1/19/2007 10:26:00 PM

nicknameoptional

1/20/2007 12:20:00 AM

> There is a good Google video about rspec and Behavior Driven
> Development by the very well-dressed Dave Astels:
>
> http://video.google.com/videoplay?docid=8135690990081075324&a...
>
> --
> James Britt
>

I still fail to see the value added by rSpec. In the video, one main
point I got was BDD try to break the 1-1 relation of class and test
class, which he said is useful if refactoring code. but writing rails
app, with convention over configuration ideology, I don't really do
that much refactoring.

and if you look at the example,
"@stack.should_be_empty" is mapped to stack.empty? method,
@stack.top.should_equal "one item" is stack.top == "one item"

besides more English like, how is it better than the assert_equal?

Sam Smoot

1/20/2007 12:53:00 AM

nicknameoptional wrote:
> besides more English like, how is it better than the assert_equal?

It's not. If you're doing TDD right, then BDD is just what you're doing
already, by another name.

The problem is a lot of people don't do TDD right, and the semantics of
it raise the barrier to entry.

BDD is about trying to change those semantics, so TDD
As-It-Was-Meant-To-Be becomes more popular. It's just a bonus that
rSpec reads so nicely and prints out nice looking reports.

So I was in the same boat as you. Then I decided: "You know, they have
a point about people misinterpreting TDD. So is trying to change the
language used to describe it really such an awful thing?"

And that's where I am now.

Is using rSpec in your projects going to increase velocity by 10%? Or
make it easier to communicate with business people? Or allow you to
write better tests? Have fewer bugs? Any of these things? No. Not if
you're already doing TDD well. It might help more developers to get
there though. It might help new team-members integrate faster with less
training on TDD and the way you're doing things. It might just give you
a warm fuzzy. Compared to a lot of the arbitrary and complex choices we
sometimes make, you could do a lot worse I think.

Lionel Bouton

1/20/2007 1:12:00 AM

nicknameoptional wrote the following on 20.01.2007 01:20 :
>> There is a good Google video about rspec and Behavior Driven
>> Development by the very well-dressed Dave Astels:
>>
>> http://video.google.com/videoplay?docid=8135690990081075324&a...
>>
>> --
>> James Britt
>>
>>
>
> I still fail to see the value added by rSpec. In the video, one main
> point I got was BDD try to break the 1-1 relation of class and test
> class, which he said is useful if refactoring code. but writing rails
> app, with convention over configuration ideology, I don't really do
> that much refactoring.
>
> and if you look at the example,
> "@stack.should_be_empty" is mapped to stack.empty? method,
> @stack.top.should_equal "one item" is stack.top == "one item"
>
> besides more English like, how is it better than the assert_equal?
>

assert_equal is ambiguous and as said in the video, many mismatch the
parameters (I've done it several times myself).
@object.method.should_equal is less prone to errors.

This specific comment aside, from what I understood from the video the
main benefit is that it helps those who don't really get the test
process with TDD not being confused by the naming used in Test::Unit. It
keeps them in the right set of mind: "How should objects in some
contexts behave?" and not "what equality/difference/basic property/...
should I test?". This single change of context doesn't seem so helpful
at first glance, but in practice I've seen numerous developers
(including myself) being drowned in tests, adding new useless or
unimportant ones because they lost focus on what they should test:
correct behaviour of the application and its components. So I believe
this approach can help ("the language shapes the thought" as mentioned
in the video is probably true from my point of view).

A good point is that it definitely enhances test readibility too.

Lionel.

nicknameoptional

1/20/2007 2:05:00 AM

> It keeps them in the right set of mind: "How should objects in some
> contexts behave?" and not "what equality/difference/basic property/...
> should I test?".

Each context in rSpec is just a new testcase. For example,
EmptyStackTest's setup() can be written "@stack = Stack.new",
FullStackTest's steup() can be written "@stack = Stack.new;
@stack.fillup...."

so a rSpec file with 5 contexts is same as 5 unit testcase files,
although I almost always only write one testcase per class. if
assert_equal is ambiguous, you always can use assert(object.attr [== |
equal | eql] "expected")

>From my point of view, same testing tasks done in rSpec is not much
easier than using existing tools (Test/unit, rails testing tools).

James Gray

1/20/2007 2:34:00 AM

On Jan 19, 2007, at 6:55 PM, Sam Smoot wrote:

> The problem is a lot of people don't do TDD right, and the
> semantics of
> it raise the barrier to entry.

Yes. This has always bothered me about the zentest tool. I love
many of the tools in that package, but the zentest tool seems to
encourage bad testing habits. The video linked to earlier in the
thread explains why.

James Edward Gray II

Gennady Bystritsky

1/20/2007 6:19:00 AM

It is worth noting that rSpec is not the only player in the field of behavior testing. It simply goes a bit further providing the whole framework in place of Test/Unit (it reads much better, for one). I use Mocha with Test/Unit for behavior/unit testing an is quite happy with the combo. I saw it mentioned somewhere that Mocha comes by default in RoR installations, so they have means for behavior testing already ;-).

Gennady.

-----Original Message-----
From: Sam Smoot [mailto:ssmoot@gmail.com]
Sent: Fri 1/19/2007 16:55
To: ruby-talk ML
Subject: Re: I don't get rspec

nicknameoptional wrote:
> besides more English like, how is it better than the assert_equal?

It's not. If you're doing TDD right, then BDD is just what you're doing
already, by another name.

The problem is a lot of people don't do TDD right, and the semantics of
it raise the barrier to entry.

BDD is about trying to change those semantics, so TDD
As-It-Was-Meant-To-Be becomes more popular. It's just a bonus that
rSpec reads so nicely and prints out nice looking reports.

So I was in the same boat as you. Then I decided: "You know, they have
a point about people misinterpreting TDD. So is trying to change the
language used to describe it really such an awful thing?"

And that's where I am now.

Is using rSpec in your projects going to increase velocity by 10%? Or
make it easier to communicate with business people? Or allow you to
write better tests? Have fewer bugs? Any of these things? No. Not if
you're already doing TDD well. It might help more developers to get
there though. It might help new team-members integrate faster with less
training on TDD and the way you're doing things. It might just give you
a warm fuzzy. Compared to a lot of the arbitrary and complex choices we
sometimes make, you could do a lot worse I think.

M. Edward (Ed) Borasky

1/20/2007 6:39:00 AM

nicknameoptional wrote:
> I just discovered rspec today, reading the example and tutorials,
> besides the doc and coverage features, I can't see how is it different
> from unit test. For my rails app, existing testing tools in rails
> already fills all my testing needs. So what does rspec do more than
> existing testing tools? Thanks.
>
> http://rspec.rubyforge.org/tools/...
>
Well ... I don't "get" Test::Unit. It just seems so complicated and
intricate. Rspec is a whole lot simpler to use, and it integrates some
good tools, like Rcov. I think it's the perfect way to learn TDD/BDD.

I do have a bone to pick with the tutorial (or maybe I don't understand
TDD/BDD yet). In the stack example, I cringe with horror when I see them
setting a method that just returns "true" simply to get a test to pass.
That grates on me, because I *know* I'm actually going to have to write
the real code eventually. It seems like a waste of time to do the
nitty-gritty "add a test to the spec/add a trivial fix to the code" cycle.

Part of that may be the algorithm I'm implementing. It's very well
defined already -- not something I have to "figure out" given a set of
behaviors. But the same is true of a stack, which is the example in the
tutorial. Everybody knows what a stack is supposed to do, everybody
knows what the output from sorting an array of strings is supposed to
be, etc. I think a better example would be something where you didn't
"instantly" know what the code should look like -- a case where you
really had some *behavior* but no code when you started developent, and
had to "create" the objects and methods and classes from the behavior.

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blo...

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

Devin Mullins

1/20/2007 7:12:00 AM

M. Edward (Ed) Borasky wrote:
> I do have a bone to pick with the tutorial (or maybe I don't understand
> TDD/BDD yet). In the stack example, I cringe with horror when I see them
> setting a method that just returns "true" simply to get a test to pass.
> That grates on me, because I *know* I'm actually going to have to write
> the real code eventually. It seems like a waste of time to do the
> nitty-gritty "add a test to the spec/add a trivial fix to the code" cycle.

It seems to be part of Kent Beck's definition of TDD. AFAICT, he excuses
it away as, "well, this bogus 'true' method will be fixed when we get to
the refactor stage -- duplication between the 'true' in the code and the
'true' in the test," but I don't really buy that.

Not all of the cases of cheating are going to be duplication -- say,
you're supposed to be implementing the gamma function, but, starting off
only testing natural numbers, you just implement fac first. AFAIK,
implementing factorial is not going to help you implement gamma.
Likewise, saying 'def size; 0 end' may make you feel better, but it's
hardly progress towards an actual implementation of #size.

In any case, if the point is to keep the cycles short and to encourage
the tests to be written, I'd at least like to inject a bit of
pragmatism. We all get interrupted, have short memories, etc. -- at the
very least, the stub implementation should be:
def empty?
true # XXX bogus code -- actual implementation pending tests
end

(Remember, imaginary folks who are the audience of this rant: Bad code
should *look* bad.)

Fondly,
Devin

Pat Maddox

1/20/2007 8:37:00 AM

On 1/19/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
> I do have a bone to pick with the tutorial (or maybe I don't understand
> TDD/BDD yet). In the stack example, I cringe with horror when I see them
> setting a method that just returns "true" simply to get a test to pass.
> That grates on me, because I *know* I'm actually going to have to write
> the real code eventually. It seems like a waste of time to do the
> nitty-gritty "add a test to the spec/add a trivial fix to the code" cycle.

First of all, it's just a simple example for people brand new to
RSpec. It's good to take baby steps. As you do it more you'll
obviously combine a couple steps into one. But if you get stuck you
can always take a few steps back and then do the baby steps.

Now for the more important theoretical point...

There are two key parts when doing TDD/BDD. The first is writing a
spec that fails. The second is getting it passing. I do that every
single time, no matter how trivial the code is. After you've been
doing BDD for a while you'll probably write a spec and then write the
code, run the spec, and move on. That'll work really well for you for
a long time. Then one day you're going to do that and your spec will
pass, but some part of the behavior still doesn't seem right. You
spend a lot of time hunting this bug down, and finally you get
frustrated and tear out the new code to start from square one. And
you run your spec...and it's green. What the hell? You just yanked
out your code. Then you realize that you wrote the wrong spec, and
vow never to skip that trivial red step again.

Pat

comp.lang.ruby

I don't get rspec

nicknameoptional

James Britt

nicknameoptional

Sam Smoot

Lionel Bouton

nicknameoptional

James Gray

Gennady Bystritsky

M. Edward (Ed) Borasky

Devin Mullins

Pat Maddox

x Login to ForumsZone