Rails - May 2008 - New to "Agile Development" - should I use RSpec or Test::Unit?

Hi everyone, I''m just now really starting to look into Agile 
Development, and so I''m trying to gauge what the Rails
community''s
preference is in regards to using RSpec versus the built-in Test::Unit. 
  I haven''t really delved much into testing in the past, I''m
sad to say,
but I understand why it''s beneficial to writing maintainable code and I
wish to start in order to become a better developer.

I am starting a new project for a potential business opportunity, and I 
would really like to use more agile techniques when designing it to A) 
Improve the quality of the code, and B) Improve my own skills since by 
and large my experience has been of the "Just hack together something 
that works" variety (not by choice, of course).

The biggest hurdle I seem to be facing is that I never seem to know what 
to test for.  I''ve read a little about Test-Driven Development in the 
past, but when I try to do it I always think that I''m testing things 
which don''t matter; the blogs and articles I''ve read seem to
give both
sides of the coin in regards to this - I''ve seen some say that
it''s bad
to test the built-in functionality of Rails (because those would have 
their own tests anyway and if something like ActiveRecord, for example, 
doesn''t work the right way internally then something is wrong with
Rails
itself, and not your code).  I''ve also seen a lot of examples that DO 
test the built-in functionality, although that might be because they are 
tutorials.

In any event, I recently learned about RSpec (actually it was from 
reading the book "The Rails Way", which suggests to use RSpec instead
of
Test::Unit), and while Behavior-Driven Development seems a little easier 
to grasp due to the English-like syntax, it brings a whole new problem: 
  Half the time I''m not sure at first what the behavior should be to 
begin with - what I mean is that I know in my head what I want to be 
able to do, but I have a hard time fleshing it out into a spec.  The BDD 
style also seems to be heavily in favor of mocking and stubbing as 
opposed to Test::Unit which has a test database, which I''ve heard about
but never done so is a little confusing as well.  It doesn''t
"feel" like
I''m really testing things, since most examples I''ve seen will
stub out
the find methods to return predefined values... so how do you know that 
it''s returning what you need?  I know that you can use fixtures with 
RSpec, but I''ve heard that this is basically tacked on instead of 
assumed like with the built-in stuff.

As a general rule I try to follow the best practices of the community, 
so I can learn from more advanced developers and also have a comparable 
skillset for the future.  In this case, however, I''m not really sure 
which path to take.

Any advice/suggestions would be greatly appreciated.  I am still sort of 
learning how Rails works... coming from a .NET background, the 
conventions are a little confusing at first and seem a little 
restrictive, but overall I am enjoying it.

- Wayne

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 20 May 2008, at 13:23, Wayne Molina wrote:
>
> Hi everyone, I''m just now really starting to look into Agile
> Development, and so I''m trying to gauge what the Rails
community''s
> preference is in regards to using RSpec versus the built-in  
> Test::Unit.
>  I haven''t really delved much into testing in the past,
I''m sad to
> say,
> but I understand why it''s beneficial to writing maintainable code
> and I
> wish to start in order to become a better developer.
>
> I am starting a new project for a potential business opportunity,  
> and I
> would really like to use more agile techniques when designing it to A)
> Improve the quality of the code, and B) Improve my own skills since by
> and large my experience has been of the "Just hack together something
> that works" variety (not by choice, of course).
>
> The biggest hurdle I seem to be facing is that I never seem to know  
> what
> to test for.  I''ve read a little about Test-Driven Development in
the
Before you write your code, think about what your code should do and  
write a test that tests that.
When you''re about to add a new feature to some code, again write the  
test first. If you find a bug, write a failing test that exhibits the  
problem and then fix the bug.

I wouldn''t fret too much about using rspec or test::unit. do whatever  
you''re comfortable with. (Personally I use test::unit. There are some  
nice bits to rspec (and some of them are available for test::unit in  
the form of shoulda) but I don''t really buy the (what I perceive to  
be) excessive use of natural language like syntaxes.
> The BDD
> style also seems to be heavily in favor of mocking and stubbing as
> opposed to Test::Unit which has a test database, which I''ve heard
> about
> but never done so is a little confusing as well.  It doesn''t
"feel"
> like
> I''m really testing things, since most examples I''ve seen
will stub out
> the find methods to return predefined values... so how do you know  
> that
> it''s returning what you need?  I know that you can use fixtures
with
> RSpec, but I''ve heard that this is basically tacked on instead of
> assumed like with the built-in stuff.
>
The idea here is that you are testing each unit in isolation: if you  
break something you want 1 failure in the tests for that bit of code,  
not 20 failures all over the app that make you spend time working  
through them before realising the problem lies in another bit of code.  
So you mock & stub to verify that you''re interacting properly with
the
other bits. This does mean that you''re not testing the integration of  
your classes with other classes to the same extent (which has both up  
and downsides). I could waffle on about this for ages, but I suggest  
you read Martin Fowler''s essay:
http://martinfowler.com/articles/mocksArentStubs.html

Fred

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

RSpec is a bit of a resource hog so I stopped using it.  And there
wasn''t a good version of Growl for Windows when I tried it.

But if you develop on a fast dual-core system with a couple of gigs of
ram, try RSpec.

F

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I prefer rspec mainly for it''s ability to truly tests in isolation...
the (virtual) elimination of fixtures and the db-dependence is well
worth the switch.

On May 20, 9:52 am, fredistic
<fredis...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> RSpec is a bit of a resource hog so I stopped using it.  And there
> wasn''t a good version of Growl for Windows when I tried it.
>
> But if you develop on a fast dual-core system with a couple of gigs of
> ram, try RSpec.
>
> F
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I would also consider "Shoulda" in that it is 100% compatible with 
existing test::Unit BUT it also extends test::unit to allow for a much 
better syntax that is more behavior oriented.

http://thoughtbot.com/projects/shoulda

The thoughtbot guys really outdid themselves with this testing framework 
in my opinion

I would also consider checking out object-daddy which is lesser known 
which is probably the most elegant way to avoid fixtures that I have 
ever seen.

http://github.com/flogic/object_daddy/tree/master

I am constantly impressed with the cool plugins that are released by the 
ruby community for testing. There is almost no excuse not to do proper 
testing.
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---