TESTING CONTROLLERS

148

The assert( ) method takes an optional message as the last parameter. We

use this in the custom assertions to provide better failure messages. If the

assertion fails, the specified message is printed for easier debugging.

Now we can rewrite test_salable_items( ) to use the custom assertions.

File 124

def test_salable_items_using_custom_assert

items = Product.salable_items

assert_equal 2, items.length

assert_salable items[0]

assert_salable items[1]

assert_not_salable @future_proof_book

end

Extracting common code into custom assertions is an important house-

keeping activity because it helps keep the tests readable and maintainable.

We’ll experience more of the benefits when we start testing controllers, the

subject of our next section.

OK, let’s take stock of where we’re at. We have confidence that at least

one model (Product) works as we expect because we have passing tests for

the basic database operations: create, read, update and delete (or CRUD,

as the database folk like to say). We also wrote tests for a business rule

in that model and ensured that required fields are validated. If you write

similar tests for all of your models, your application will be in good shape.

Now let’s turn our attention to the controllers.

TESTING CONTROLLERS

149

As the LoginController was created with the generate controller script, Rails

has a test stub waiting for us in the test/functional directory.

File 117

require File.dirname(__FILE__) + '/../test_helper'

require 'login_controller'

# Re-raise errors caught by the controller.

class LoginController; def rescue_action(e) raise e end; end

class LoginControllerTest < Test::Unit::TestCase

def setup

@controller = LoginController.new

@request

= ActionController::TestRequest.new

@response

= ActionController::TestResponse.new

end

# Replace this with your real tests.

def test_truth

assert true

end

end

Notice that the setup( ) method has already initialized the three primary

objects we’ll need to test a controller: @controller, @request, and @response.

These are especially handy because using them means we don’t have to

fire up the web server to run controller tests. That is, functional tests

don’t necessarily need a web server or a network.

Index: For Admins Only

Great, now let’s take the hint and replace the generated test_truth( ) method

with our first controller test—a test that simply “hits” the login page.

File 117

def test_index

File 117

def test_index_without_user

get :index

assert_redirected_to :action => "login"

assert_equal "Please log in", flash[:notice]

end

TESTING CONTROLLERS

151

The test, then, simply stuffs the user information in the request and sends

it on to the login( ) action.

File 117

def test_login_with_invalid_user

post :login, :user => {:name => 'fred', :password => 'opensesame'}

assert_response :success

assert_equal "Invalid user/password combination", flash[:notice]

end

This time we use the post( ) method, another convenience method loaded

by the test helper, to send a request to the login( ) action, which differ-

entiates its behavior depending on the HTTP access method. Along with

the request, we send a hash of request parameters representing the user.

Since the user is invalid, the test expects the login to fail with a flash notice

on the resulting page.

depot> ruby test/functional/login_controller_test.rb

Loaded suite test/functional/login_controller_test

Started

.

Finished in 0.128031 seconds.

2 tests, 4 assertions, 0 failures, 0 errors

Sure enough, the test passes. Fred can’t possibly log in because we don’t

have any users in the database. Now, we could try adding Fred using the

add_user( ) action, but we have to be logged in as an administrator to do

that. We could also create a valid User object and save it to the database

just for this test case, but we’re likely to need User objects in other test

cases. Instead, we’ll use our old friend the fixture, this time defined in the

file test/fixtures/users.yml.

File 116

fred:

id: 1

name: fred

hashed_password: <%= Digest::SHA1.hexdigest('abracadabra') %>

The users table wants the hashed password, not the plain-text password.

Therefore, we embed Ruby code in the fixture file to generate a hashed

password from a plain-text one. (Remember, this is the test database, so

putting the plain-text password in the fixture file shouldn’t set off alarms

for the security police.) Then we have to explicitly load the users fixture in

the LoginControllerTest.

File 117

fixtures :users

We rerun the test_login_with_invalid_user( ) test, and again it passes—Fred

still can’t log in. This time he hasn’t supplied the proper password. At this

point, we change the test_login_with_invalid_user( ) test to use a user name

that’s not in the database. We also write a test_login_with_invalid_password( )

test that tries to log in Fred (who is now in the database, courtesy of the

TESTING CONTROLLERS

152

fixture) using a bad password. Both of those tests pass, so we’ve got our

bases covered.

Login: Valid User

Next we write a test that verifies that Fred can log in given the correct

password listed in the fixture file.

File 117

def test_login_with_valid_user

post :login, :user => {:name => 'fred', :password => 'abracadabra'}

assert_redirected_to :action => "index"

assert_not_nil(session[:user_id])

user = User.find(session[:user_id])

assert_equal 'fred', user.name

end

In this case, we expect to get Fred logged in and redirected to the index( )

action. While we’re at it, we check that the user in the session is indeed

Fred. That’s Fred’s meal ticket to getting around the admin side of the

application.

We run the test, and it passes! Before moving on, we have an opportunity

here to make writing more controller tests easier. We’ll need to be logged

in to do any sort of testing of the admin features. Now that we have a login

test that works, let’s extract it into a helper method in the test_helper.rb file.

File 122

def login(name='fred', password='abracadabra')

post :login, :user => {:name => name, :password => password}

TESTING CONTROLLERS

156

redirect_to_url

The full URL that the previous action redirected to.

assert_equal "http://test.host/login", redirect_to_url

We’ll see more of these assertions and variables in action as we write more

tests, so let’s get back to it.

Buy Something Already!

The next feature we’d be wise to test is that a user can actually place an

order for a product. That means switching our perspective over to the

storefront. We’ll walk through each action one step at a time.

Listing Products for Sale

Back in the StoreController, the index( ) action puts all the salable products

into the @products instance variable. It then renders the index.rhtml view,

which uses the @products variable to list all the products for sale.

To write a test for the index( ) action, we need some products. Thankfully,

we already have two salable products in our products fixture. We just need

to modify the store_controller_test.rb file to load the products fixture. While

we’re at it, we load the orders fixture, which contains one order that we’ll

need a bit later.

File 119

require File.dirname(__FILE__) + '/../test_helper'

require 'store_controller'

TESTING CONTROLLERS

157

using explicit test fixtures, we don’t need to do this; the fixture takes care

of deleting data for us. In this case, though, we’re adding line items but

we aren’t using a line items fixture, so we have to tidy up manually.

Then we add a test_index( ) method that requests the index( ) action and

verifies that the store/index.rhtml view gets two salable products.

File 119

def test_index

get :index

assert_response :success

assert_equal 2, assigns(:products).size

assert_template "store/index"

end

You may be thinking we have gratuitous overlap in testing here. It’s true,

we already have a passing unit test in the ProductTest test case for salable

items. If the index( ) action simply uses the Product to find salable items,

aren’t we covered? Well, our model is covered, but now we need to test that

the controller action handles a web request, creates the proper objects for

the view, and then renders the view. That is, we’re testing at a higher level

than the model.

Could we have simply tested the controller and, because it uses the model,

not written unit tests for the model? Yes, but by testing at both levels we

can diagnose problems quicker. If the controller test fails, but the model

test doesn’t, then we know there’s a problem with the controller. If, on

the other hand, both tests fail, then our time is best spent focusing on the

model. But enough preaching.

Adding to the Cart

Our next task is to test the add_to_cart( ) action. Sending a product id

in the request should put a cart containing a corresponding item in the

session and then redirect to the display_cart( ) action.

File 119

def test_add_to_cart

get :add_to_cart, :id => @version_control_book.id

TESTING CONTROLLERS

158

able and assert_template( ) assertion use the results of the display_cart( )

action, rather than the original add_to_cart( ) action. In this case, the

display_cart( ) action should render the display_cart.rhtml view, which has

access to the @items instance variable.

The use of the symbol parameter in assigns(:items) is also worth discussing.

For historical reasons, you cannot index assigns with a symbol—you must

use a string. Because all the cool dudes use symbols, we instead use the

method form of assigns, which supports both symbols and strings.

We could continue to walk through the whole checkout process by adding

successive assertions in test_add_to_cart( ), using follow_redirect( ) to keep

the ball in the air. But it’s better to keep the tests focused on a single

request/response pair because fine-grained tests are easier to debug (and

read!).

Oh, while we’re adding stuff to the cart, we’re reminded of the time when

the customer, while poking and prodding our work, maliciously tried to

add an invalid product by typing a request URL into the browser. The

application coughed up a nasty-looking page, and the customer got ner-

vous about security. We fixed it, of course, to redirect to the index( ) action

and display a flash notice. The following test will help the customer (and

us) sleep better at night.

File 119

def test_add_to_cart_invalid_product

get :add_to_cart, :id => '-1'

assert_redirected_to :action => 'index'

assert_equal "Invalid product", flash[:notice]

end

Checkout!

Let’s not forget checkout. We need to end up with an @order instance

variable for the checkout.rhtml view to use.

File 119

def test_checkout

test_add_to_cart

get :checkout

assert_response :success

assert_not_nil assigns(:order)

TESTING CONTROLLERS

159

Save the Order

Last, but certainly not least, we need to test saving an order through the

save_order( ) action. Here’s how it’s supposed to work: the cart dumps its

items into the Order model, the Order gets saved in the database, and the

cart is emptied. Then we’re redirected back to the main store page where

a kind message awaits.

We’ve mostly been testing the happy path so far, so let’s switch it up by try-

ing to save an invalid order, just so we don’t forget about writing boundary

condition tests.

File 119

def test_save_invalid_order

test_add_to_cart

post :save_order, :order => {:name => 'fred', :email => nil}

assert_response :success

assert_template "store/checkout"

assert_tag :tag => "div", :attributes => { :class => "fieldWithErrors" }

assert_equal 1, session[:cart].items.size

end

We need items in the cart, so this test starts by calling test_add_to_cart( )

(sounds like we need another custom assertion). Then an invalid order

is sent through the request parameters. When an invalid order is sub-

mitted through the checkout.rhtml view, we’re supposed to see red boxes

around the fields of the order form that are required but missing. That’s

easy enough to test. We cast a wide net by using assert_tag( ) to check the

response for a div tag with fieldWithErrors as its class attribute. Sounds like

a good opportunity to write another set of custom assertions.

File 122

def assert_errors

assert_tag error_message_field

end

TESTING CONTROLLERS

160

Excellent! Now that we know an invalid order paints fields on the page

red, let’s add another test to make sure a valid order goes through cleanly.

File 119

def test_save_valid_order

test_add_to_cart

assert_equal 1, session[:cart].items.size

assert_equal 1, Order.count

post :save_order, :order => @valid_order_for_fred.attributes

assert_redirected_to :action => 'index'

assert_equal "Thank you for your order.", flash[:notice]

follow_redirect

assert_template "store/index"

assert_equal 0, session[:cart].items.size

assert_equal 2, Order.find_all.size

end

Rather than creating a valid order by hand, we use the @valid_order_for_fred

instance variable loaded from the orders fixture. To put it in the web

request, call its attributes( ) method. Here’s the orders.yml fixture file.

File 113

valid_order_for_fred:

id: 1

name: Fred

email: fred@flintstones.com

address: 123 Rockpile Circle

pay_type: check

We’re becoming pros at this testing stuff, so it’s no surprise that the test

passes. Indeed, we get redirected to the index page, the cart is empty, and

two orders are in the database—one loaded by the fixture, the other saved

by the save_order( ) action.

OK, so the test passes, but what really happened when we ran the test?

The log/test.log file gives us a backstage pass to all the action. In that file

we find, among other things, all the parameters to the save_order( ) action

and the SQL that was generated to save the order.

Processing StoreController#save_order (for at Mon May 02 12:21:11 MDT 2005)

Parameters: {"order"=>{"name"=>"Fred", "id"=>1, "pay_type"=>"check",

"shipped_at"=>Mon May 02 12:21:11 MDT 2005, "address"=>"123 Rockpile Circle",

"email"=>"fred@flintstones.com"}, "action"=>"save_order", "controller"=>"store"}

SQL (0.000298)

BEGIN

SQL

(0.000219)

COMMIT

SQL

(0.000214)

BEGIN