rspec users - Jul 2009 - noob question (trying to understand view specs vs webrat and cucumber)...

Hey Everyone,

I''ve been reading the rspec book, and I''m trying to tie
everything
together, but I''m a little confused. Keep in mind this is my first
introduction to TDD/BDD. When it came to testing my rails app I jumped
into learning rspec before I ever tried to using any of the built in
test:unit stuff. I''m probably a different breed because of this, most
everyone else has probably been using the stuff built into rails
before ever attempting rspec or cucumber. I didn''t see the need to
learn something that everyone is going away from, but if it''s a
necessary evil please let me know.

I am to the chapter talking about writing view specs, this chapter is
preceded by a chapter that talks about using webrat matchers to help
you test views, and uses cucumber step definitions. I''m having a
problem understanding when I should use cucumber and when I should use
rspec. If I start my app coding by "spec"ing my views then do I really
need to use cucumber at all? Can someone clarify in "simple" terms the
relationship between rspec and cucumber. I feel I understand them
independently, but I''m confused on how and when I choose to use them
together. I have read through the book pretty thoroughly to this point
and feel I have absorbed everything there is to absorb, but my mind
isn''t getting this correlation. When going through the codebreaker
example it had me run my cucumber stuff separate from my rspec stuff.
Looking back it seems the only reason I used both was to develop a
more complete test, but in fact I could use one over the other if I
wanted to? That statement makes sense "to me", but I know
it''s
probably wrong.

I guess while I''m asking questions, I''ll ask one more...

 If I want to follow the BDD mantra to the tee, then I would spec all
of my views first, and use this as my starting place for adding every
subsequent test after that right? After the views have been "spec"ed
and are re-factored in the "Green" then I would re-factor again by
adding controller methods or model information to get rid of my stub
code. Am I understanding that correctly?

Any information helps me learn.

Thanks!

Chris

Hi Chris,

On 16 Jul 2009, at 04:14, Chris Sund wrote:
> Can someone clarify in "simple" terms the relationship between
rspec
> and cucumber.
Very short answer:

RSpec is for specifying the behaviour of individual pieces of your  
application, ideally in isolation from all of the other pieces. The  
mocking framework allows you to write specs for each separate piece  
(e.g. each class) in a way that doesn''t depend on any of the other  
pieces: "Assuming that pieces A and B and C behave in the way
they''re
supposed to, piece D should behave like this...". This gives you a way  
to drive the actual implementation of your application in detail, at  
the level of individual methods doing simple jobs.

Cucumber is for specifying/testing the overall behaviour of your  
application. Whereas RSpec exercises each individual piece in  
isolation, Cucumber exercises the interactions between all of the  
pieces, and allows you to check what happens when several such  
interactions happen in a particular order (e.g. a user playing a  
complete game of Codebreaker, or going through the complete checkout/ 
payment process in a web application). Whereas RSpec examples are very  
fine-grained and implementation-focused, Cucumber features are meant  
to be broad and high-level in a way that makes them meaningful to  
actual users of the application (or the customers who are asking for  
it to be built) rather than just programmers.

One way of thinking about this is that your specs make all sorts of  
assumptions about how the rest of the system is meant to behave, and  
Cucumber is a way of actually checking those assumptions by running  
the system as a whole.

Cheers,
-Tom

Tom,

I appreciate the reply...

So would I be correct in saying that I should develop all of my spec
tests first, and then finish it up by running some cucumber tests?

Thanks!

Chris

On Jul 15, 11:34?pm, Tom Stuart <t... at experthuman.com>
wrote:
> Hi Chris,
>
> On 16 Jul 2009, at 04:14, Chris Sund wrote:
>
> > Can someone clarify in "simple" terms the relationship
between rspec ?
> > and cucumber.
>
> Very short answer:
>
> RSpec is for specifying the behaviour of individual pieces of your ?
> application, ideally in isolation from all of the other pieces. The ?
> mocking framework allows you to write specs for each separate piece ?
> (e.g. each class) in a way that doesn''t depend on any of the other
?
> pieces: "Assuming that pieces A and B and C behave in the way
they''re ?
> supposed to, piece D should behave like this...". This gives you a way
?
> to drive the actual implementation of your application in detail, at ?
> the level of individual methods doing simple jobs.
>
> Cucumber is for specifying/testing the overall behaviour of your ?
> application. Whereas RSpec exercises each individual piece in ?
> isolation, Cucumber exercises the interactions between all of the ?
> pieces, and allows you to check what happens when several such ?
> interactions happen in a particular order (e.g. a user playing a ?
> complete game of Codebreaker, or going through the complete checkout/
> payment process in a web application). Whereas RSpec examples are very ?
> fine-grained and implementation-focused, Cucumber features are meant ?
> to be broad and high-level in a way that makes them meaningful to ?
> actual users of the application (or the customers who are asking for ?
> it to be built) rather than just programmers.
>
> One way of thinking about this is that your specs make all sorts of ?
> assumptions about how the rest of the system is meant to behave, and ?
> Cucumber is a way of actually checking those assumptions by running ?
> the system as a whole.
>
> Cheers,
> -Tom
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

Hi Chris,

On 16 Jul 2009, at 06:46, internetchris  
<chris at silhouettesolutions.net> wrote:
> So would I be correct in saying that I should develop all of my spec
> tests first, and then finish it up by running some cucumber tests?
You can do whatever you like. This is certainly a valid way of  
working, and as a testing strategy it would definitely help you to  
catch certain kinds of bugs that you might miss with RSpec alone.

However, BDD is about the design process itself, not (just) testing,  
and the BDD people (and the RSpec book) recommend a process where you  
start at the Cucumber level, i.e. think first about an overall feature  
that you want your application to have, and write that feature up as  
Cucumber scenarios. Although those scenarios will all fail (because  
you haven''t written any code yet), they represent what you''re
aiming
for. To get them to pass you "drop down" into RSpec and write some  
more detailed specs for the behaviour you think you''ll need to get the
Cucumber scenarios passing, and actually implement the code (to make  
the specs pass) as you go. When all the specs pass then the Cucumber  
feature will also pass unless you''ve forgotten something. Then you  
move onto writing another Cucumber feature and the design/implement  
cycle continues.

I''m pretty sure there''s a diagram of this process (concentric
circles
with arrows) in the first couple of chapters of the RSpec book.

Cheers,
-Tom

On Thu, Jul 16, 2009 at 7:46 AM,
internetchris<chris at silhouettesolutions.net>
wrote:
> Tom,
>
> I appreciate the reply...
>
> So would I be correct in saying that I should develop all of my spec
> tests first, and then finish it up by running some cucumber tests?
>
> Thanks!
>
> Chris
>
Chris

If you follow strict Behaviour Driven Development, then the behaviour
should be defined before the code. Therefore, the Cucumber scenarios
should come first.

My workflow is like this:
Write Cucumber scenario - It will fail because the path isn''t defined
Create route entry
Run Cucumber - It now fails because the controller doesn''t exist
Create controller spec - It will fail because there''s no controller
Create controller
Spec now fails because required model doesn''t exist
Write model spec - It will fail because model doesn''t exist
Create model
Flesh out model until model spec passes
Flesh out controller until controller spec passes
Continue until Cucumber scenario passes
Repeat until project is complete :-)

I run autospec so most of the test re-runs are done automatically and
therefore the process continues a lot more smoothly than it sounds.
You''ll notice that their are no view specs. I don''t use view
specs 95%
of the time because Cucumber covers this (previously my view specs
where just an assertion that the view was there).
When theirs something very specific I need to ensure is in the view, I
might add a view spec.

Andrew Timberlake
http://ramblingsonrails.com

http://MyMvelope.com - The SIMPLE way to manage your savings

Very nice.... the ability to see your workflow helps me a ton. I guess
I needed to see what other developers did. I have a project that I
started, but then quit until I nailed down the testing. I will have to
catch up on the code I have already written, but I''m grasping the
cucumber and rspec correlation now. On anything new I will start with
Cucumber and then to rspec to iron out the actual code.

Thanks!

Chris

On Jul 16, 12:47?am, Andrew Timberlake <and... at andrewtimberlake.com>
wrote:
> On Thu, Jul 16, 2009 at 7:46 AM,
>
> internetchris<ch... at silhouettesolutions.net> wrote:
> > Tom,
>
> > I appreciate the reply...
>
> > So would I be correct in saying that I should develop all of my spec
> > tests first, and then finish it up by running some cucumber tests?
>
> > Thanks!
>
> > Chris
>
> Chris
>
> If you follow strict Behaviour Driven Development, then the behaviour
> should be defined before the code. Therefore, the Cucumber scenarios
> should come first.
>
> My workflow is like this:
> Write Cucumber scenario - It will fail because the path isn''t
defined
> Create route entry
> Run Cucumber - It now fails because the controller doesn''t exist
> Create controller spec - It will fail because there''s no
controller
> Create controller
> Spec now fails because required model doesn''t exist
> Write model spec - It will fail because model doesn''t exist
> Create model
> Flesh out model until model spec passes
> Flesh out controller until controller spec passes
> Continue until Cucumber scenario passes
> Repeat until project is complete :-)
>
> I run autospec so most of the test re-runs are done automatically and
> therefore the process continues a lot more smoothly than it sounds.
> You''ll notice that their are no view specs. I don''t use
view specs 95%
> of the time because Cucumber covers this (previously my view specs
> where just an assertion that the view was there).
> When theirs something very specific I need to ensure is in the view, I
> might add a view spec.
>
> Andrew Timberlakehttp://ramblingsonrails.com
>
> http://MyMvelope.com- The SIMPLE way to manage your savings
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

On 16 Jul 2009, at 17:28, internetchris wrote:
> Very nice.... the ability to see your workflow helps me a ton. I guess
> I needed to see what other developers did. I have a project that I
> started, but then quit until I nailed down the testing. I will have to
> catch up on the code I have already written, but I''m grasping the
> cucumber and rspec correlation now. On anything new I will start with
> Cucumber and then to rspec to iron out the actual code.
Have you seen these:
http://railscasts.com/episodes/155-beginning-with-cucumber
http://railscasts.com/episodes/159-more-on-cucumber

They''ll give you a good feel for how to get started with your cukes.
> Thanks!
>
> Chris
>
> On Jul 16, 12:47 am, Andrew Timberlake <and... at
andrewtimberlake.com>
> wrote:
>> On Thu, Jul 16, 2009 at 7:46 AM,
>>
>> internetchris<ch... at silhouettesolutions.net> wrote:
>>> Tom,
>>
>>> I appreciate the reply...
>>
>>> So would I be correct in saying that I should develop all of my
spec
>>> tests first, and then finish it up by running some cucumber tests?
>>
>>> Thanks!
>>
>>> Chris
>>
>> Chris
>>
>> If you follow strict Behaviour Driven Development, then the behaviour
>> should be defined before the code. Therefore, the Cucumber scenarios
>> should come first.
>>
>> My workflow is like this:
>> Write Cucumber scenario - It will fail because the path isn''t
defined
>> Create route entry
>> Run Cucumber - It now fails because the controller doesn''t
exist
>> Create controller spec - It will fail because there''s no
controller
>> Create controller
>> Spec now fails because required model doesn''t exist
>> Write model spec - It will fail because model doesn''t exist
>> Create model
>> Flesh out model until model spec passes
>> Flesh out controller until controller spec passes
>> Continue until Cucumber scenario passes
>> Repeat until project is complete :-)
>>
>> I run autospec so most of the test re-runs are done automatically and
>> therefore the process continues a lot more smoothly than it sounds.
>> You''ll notice that their are no view specs. I don''t
use view specs
>> 95%
>> of the time because Cucumber covers this (previously my view specs
>> where just an assertion that the view was there).
>> When theirs something very specific I need to ensure is in the  
>> view, I
>> might add a view spec.
>>
>> Andrew Timberlakehttp://ramblingsonrails.com
>>
>> http://MyMvelope.com- The SIMPLE way to manage your savings
>> _______________________________________________
>> rspec-users mailing list
>> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
cheers,
Matt

+447974 430184
matt at mattwynne.net
http://mattwynne.net