1. Technology
You can opt-out at any time. Please refer to our privacy policy for contact information.

A Quick Tour of a Rails Project


A Quick Tour of a Rails Project

You've just generated a new Ruby on Rails project, but now what? All you got were a bunch of directories, a lot of them empty, more of them holding mostly empty Ruby files. Where do you go? What do you do? What does it all mean?

The app directory is where most work happens. It holds all of the code for your web application. In it are a few directories like models/, views/ and controllers. It's no big surprise that this is where your models, views and controllers will go. Right now they should be empty except an Application controller (the parent class for all of your future controllers) and its layout in the views/layouts/ directory.

Another directory of note is the app/helpers/ directory. Helpers are (usually) small methods that DRY out and lighten views. Rails is of the philosophy that views should be as light as possible, having as little code in them as possible. Code in views often gets lost in the shuffle, getting mixed up with markup and forgotten about. Another big concern is that it's very difficult for code in views to be tested, so code is often removed from views and put into helpers. In this directory, for every controller that's generated, a new helper for that controller will be generated.

The last directory here is the mailers/ directory. Mailers (not surprisingly) are used to send email. Mailers abstract the process of sending off emails, such as account verification emails, such that application code doesn't need to know the details. Mailers must be generated manually, they are not generated automatically using any scaffolding or other such commands.

The config/ directory holds a number of important files. Here, you'll configure your database with database.yml, and there are various Ruby files that have to do with the environment and how your application starts up. And finally, this directory holds the routes.rb file, which you'll be coming back to often.

The public/ directory holds various files that are served statically. Things like robots.txt, the 404 page, etc. You'll be coming back to this one shortly, so make a note of it.

The log/ directory is a very important one. If and when something goes wrong, it's the first place you should turn. This directory holds web server logs that will give you insight into what your Rails application is doing, and holds any error messages that might be useful in debugging. Though it's not something you'll ever add files to, and doesn't get checked in by git.

The config.ru is your Rack configuration file. Rails uses Rack to interface with web servers. Rack is a kind of middleware, it knows how to talk to all kinds of web servers, and Rails only needs to know how to talk to Rack.

The Gemfile is the familiar Bundler file. It holds all of the dependencies for your Rails application, as well as their version numbers. If you need to use a gem in your web application, it will need to be added to this file, and Bundler will take care of the rest.

The Rakefile is the entry point for all manner of rake tasks having to do with your project. Everything from running tests to creating the database and clearing the logs can be done via the rake command line tool. To get a full list of the tasks in your project, run rake --tasks.

The test/ directory seems like it's something you can skip, maybe it's a directory for quick test code? No, this is where all of your test-driven development will happen. This, alongside the app directory, is where most of the work is done.

If you're using test-driven development (and really, you should be with a Rails application), then you write your tests in here first, run your tests and watch them fail, then implement the feature and test again. Inside this directory you'll find unit/ and functional/ tests. Unit tests test your model, these are the lowest level and most important, as the state of your entire application depends on the model. Functional tests test controllers, this both tests the integrity of the model and the function of the controllers.

The last type of test here, integration tests, are a bit more complex. These are the highest level tests and deal with the actual HTML and Javascript emitted by your web application. These tests test processes like "If I open the front page, click on the login link and enter correct credentials, I should be redirected back to the front page and I should be logged in." These tests are for testing sequences of actions as seen by the user. Not everyone does integration tests, since if your model and controller are functioning correctly then it should be producing correct output (and there's not much that can go wrong in a view). But more tests are always good.

  1. About.com
  2. Technology
  3. Ruby
  4. Ruby on Rails
  5. Ruby on Rails 3 Tutorials
  6. A Quick Tour of a Rails Project

©2014 About.com. All rights reserved.