cucumber

ntegration framework. This tests your whole stack end-to-end. Depending on what you are building this may be the only way to test it, and for a lot of people they are just doing Unit + Integration tests and not writing any controller tests. You write in Gherkin (http://github.com/aslakhellesoy/cucumber/wiki/gherkin) which is a special subset of English. You can also use Steak (http://jeffkreeftmeijer.com/2010/steak-because-cucumber-is-f...) which lets you write your story in pure Ruby. Either way, this story is broken out in to steps and then some driver follows those steps, either driving or emulating a web browser. The original driver was Webrat, which you can think of as a web browser in Ruby. Webrat has been replaced by Capybara which is more complete and has pluggable backends, including Selenium. If you aren't using much JavaScript you can stay in pure Ruby and your tests will be parsing the HTML with something like Nokogiri, this is also pretty fast. If you have complex JS you can actually drive Selenium which in turn will drive a real browser (you can even drive flock of different browsers). Depending on how complex you get this can be a total PITA, so I would start simple with just getting it running in pure Ruby and maybe testing your sign-up form. Story -> Cucumber -> Capybara -> Selenium -> Firefox... its a lot of layers and as a result can be suuuuuuper slow. Factories: Instead of pre-loading a database with stuff (fixtures), factories let you write code that returns prepped objects for you. ActiveRecord takes a row from a table and converts it to an Object (Object Relational Mapper - ORM). Say a post from the posts table into a Post object. Factory Girl will just make you a Post object. I much prefer factories because you can actually get a stack trace to figure out where all the data came from instead of shifting between a SQL database, a YAML file, and a Ruby file to find your 'fixture fail'. There are some variations on preferred syntax and Factory Girl supports most of them. Shoulda: Just some macros to save you typing. Most of them work in both Test/Unit and Rspec. Instead of writing a test like this to ensure there is a validation error if number in't a number: http://gist.github.com/649419 Just saves you time and typing, at the expense of learning the helpers. A good test is something that breaks when the code breaks. Start small, test a few 3 line methods and then build up successively higher tests. Read the tests of some projects on github to get a feel for what they're looking to test, and how they approach it. Then just ask a lot of questions.