The structure is one thing, but what about when I want to automatically create sample data?

Enter fixtures. Fixtures is a fancy word for ‘sample data’. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent and assume one of two formats: YAML or CSV.

The objective of this howto is to write a functional test to verify that a user creation form and action actually creates a user.

RubyOnRails comes with built-in support for unit and functional testing – great for us test-driven development whackos. In a new rails application we’re developing, we used the excellent salted hash login generator to kick off the development of our site’s authentication. The login generator ships with tests – yippee! Since it’s a widely used extension for rails, it makes a useful example for some testing best practices that we’ve adopted.

While playing around programming my first ecommerce application with Ruby on Rails, I felt like trying out some serious stuff like integrating PayPal web services and found some good info-threads on Google groups for soap4r and even a test script on the Ruby on Rails wiki. With all this help, I still struggled for a few hours to get things to work and the causes of errors were annoyingly banal (as usual...huh). I had to make some very minor corrections in the test code on the wiki to make the Pa ...

When you’ve built a database that includes foreign key constraints between parent and child tables, loading fixtures using rake load_fixtures and unit testing can fail with errors such as:

Mysql::Error: #23000Cannot add or update a child row: a foreign key constraint fails (`depot_development/line_items`, CONSTRAINT `fk_items_product` FOREIGN KEY (`product_id`) REFERENCES `products` (`id`) ON DELETE CASCADE): INSERT INTO line_items (`quantity`, `product_id`, `id`, `unit_price`) ...

This article is for fellow Rubyists looking for more information on test writing and how that fits into Ruby On Rails. If you’re new to test writing or experienced with test writing, but not in Rails, hopefully you’ll gain some practical tips and insight on successful testing.

If you need to test an application that uses a has_and_belongs_to_many (habtm) relationship, you’ll need to do a few extra things to your testing setup. Since it took me a bit of poking to 1. figure out that the habtm relationship wasn’t happening automagically in the tests, and 2. figure out how to make it happen, I thought I would jot down a few notes that may help others.

In a nutshell, test-driven development means writing tests before you start the implementation of a piece of functionality. From the (excellent) book, Agile Web Development with Rails – “Think of it as a specification for how you want the code to work. When the test passes, you know you’re done coding. Better yet, you’ve added one more test to the application.”

Here is how I would go about this process in Rails. I’ll be taking the example of a simpl ...