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 recommended.
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 MORE. 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.
