views:

227

answers:

5

We have chosen to use rails to build a small project of ours. This is a really small project and will likely take six man-months or less. All people working on the project are new to Rails and have limited amount of experience in web coding.

Our software is supposed to give users an easy-to-use interface to browse vast quantities of measurement data and visualization. Users identify themselves using a user account which limits which data they can see.

What sort of automated tests should we do and are there any freely available tutorials that would help us in this?

A: 

For all things rails, there are railscasts. Here's a a good one on testing with rspec: Link! (browse around to find more good stuff), and I could not recommend autotest more highly. After that, there is a lot of things you can do, depending on the test you want to write. (selenium, fixtures)

Todd Gardner
A: 

Unit testing is great and all but I think it's worth at least checking out blackbox testing

Sam
A: 

You might also want to get the book Agile Web Development with Rails. There is a chapter on using the rails testing system.

For higher level tests, you can look at Watir or Fitnesse or Selenium.

Kathy Van Stone
A: 

Thoughtbot's Shoulda is a very easy to use and intuitive testing framework, with natual language options and not much "magic" that has to be learned through tutorials and api reading.

Dave Thomas, one of the authors of the fantastic Rails book Agile Web Development with Rails offers a good, quick overview of Shoulda.

Arrel
+2  A: 

Consider the three "legs" of the MVC (model-view-controller) design pattern on which Rails is based.

Views

These should be largely devoid of business logic: code should be concerned with display of data and manipulation of the UI only.

Controllers

Minimal logic (conventional wisdom is to work with "thin controllers"). Testing (in the 'test/functional' directory) should be straightforward and - hopefully - mostly concerned with navigation and response content verification. Start with the idea of keeping these as simple as possible for as long as possible, so you'll be ready for the more complex testing topics when they're needed.

Models

This is where the business/domain logic lives. Keeping it in models makes it easier to test, which is good because you should be writing most of your tests against the models, particularly in the earliest period of development. Using tests to define behaviour before it's implemented has the added benefit of steering your code towards a cleaner, decoupled design, so try to do that as much as possible.

It's probably worth looking at Noel Rappin's Rails Prescriptions - there's a book and a (free) introductory PDF that covers Rails-specific test issues in some detail.

Mike Woodhouse