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.