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

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

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.