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

On 20 May 2008, at 13:23, Wayne M. wrote:

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.

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 F.'s essay:
http://martinfowler.com/articles/mocksArentStubs.html

Fred

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

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.

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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs