I just went through this experience myself and I will tell you that
there are many competing philosophies about testing, all of which use
similar or identical terminology to mean or assume significantly
different things. There is a vast overlap, but on a few crucial
details there are vital differences whose apparent importance is
magnified by the abysmal state of ones own ignorance. I found this to
be exceptionally confusing in the beginning and the source of much
misdirected effort on my part. For what it is worth I eventually
settled on continuous integration testing for my Rails project. For
this I use Cucumber, originally an offshoot of RSpec but now a
completely distinct and independent package.
The best places to start are the mailing lists devoted to testing. I
can recommend both the RSpec and Cuke lists as places where
extraordinarily knowledgeable and helpful people frequent. Both ML
are replicated at and can be joined through groups.google.com (http://
groups.google.com/group/rspec and http://groups.google.com/group/cukes).
There are also numerous self-help tutorials on the web. Just google
(rails ruby testing tutorial).
At my last count, Ryan Bates screencasts at railscast.com provided no
fewer than ten episodes either directly about testing or having
testing as a significant component of his presentation. Plus there
is a treasure trove of other riches to be had at his site. Highly
Recall to mind frequently that TDD/BDD is above all else a mental
approach to computer systems development. The three rules that I have
been taught are:
Write no production code AT ALL until you have a failing test.
Write only the minimal test that fails the current requirement, AND NO
Write only enough production code to pass the test, AND NO MORE.
It is hard to say which of these rules is the hardest to follow. In
the beginning I suppose it has to be rule number one for most people.
But after a time that becomes routine and the danger of not following
rules two and three become evident. In truth, you must follow all
three rules at all times. TDD/BDD just does not happen until you do.
people call what they do TDD or BDD when they write tests, or specs or
features or whatever; but if they do not rigorously follow the canon
respecting what, when and how much code to write then they are really
not. It just superficially appears that they are.
The real test for yourself is the truthful answer to the question: Is
what I am doing HARD? If the answer is no then you are missing
something important (or are a savant). TDD and BDD is HARD. It is
VERY HARD. Because you have to cast your every design intent as a
programatically testable manifestation. That means you have to think
very carefully about precisely what you NEED to accomplish and HOW to
accomplish it, whereas most people spent most of the time thinking
about what they WANT to accomplish.
If you would like to see an excellent presentation on the grim
realities of practicing TDD, this forms the core of a very discursive
talk by Bob Martin given at RailsConf2009 entitled "What Killed
Smalltalk Could Kill Ruby, Too", http://railsconf.blip.tv/file/2089545/.
You have to get past the first five minutes or so which, as far as I
could determine, have nothing to do with the subject of his
presentation. His assistant however, is the author of Cucumber.