length validation; in Listing 615 we constrained the name attribute to be 50 characters or less using the :maximum option:

validates :name,

:presence => true, :length => { :maximum => 50 }

For the password length validation, instead we ve used the :within option, passing it the range1 640 to enforce the desired length constraints

At this point, you may be concerned that we re not storing user passwords anywhere; since we ve elected to use a virtual password, rather than storing it in the database, it exists only in memory How can we use this password for authentication The solution is to create a separate attribute dedicated to password storage, and our strategy will be to use the virtual password as raw material for an encrypted password, which we will store in the database upon user signup ( 8) and retrieve later for use in user authentication ( 9) Let s plan to store the encrypted password using an encrypted_password attribute in our User model We ll discuss the implementation details in Section 72, but we can get started with our encrypted password tests by noting that the encrypted password should at the least exist We can test this using the Ruby method respond_to , which accepts a symbol and returns true if the object responds to the given method or attribute and false otherwise:

$ rails console --sandbox >> user = Usernew >> userrespond_to (:password) => true >> userrespond_to (:encrypted_password) => false

We can test the existence of an encrypted_password attribute with the code in Listing 73, which uses RSpec s respond_to helper method

describe User describe "password encryption" do before(:each) do @user = Usercreate!(@attr) end it "should have an encrypted password attribute" do @usershould respond_to(:encrypted_password) end end end

Note that in the before(:each) block we create a user, rather than just calling Usernew We could actually get this test to pass using Usernew, but (as we ll see momentarily) setting the encrypted password will require that the user be saved to the database Using create! in this first case does no harm, and putting it in before(:each) will allow us to keep all the encrypted password tests in one describe block To get this test to pass, we ll need a migration to add the encrypted_password attribute to the users table:

Here the first argument is the migration name, and we ve also supplied a second argument with the name and type of attribute we want to create (Compare this to the original generation of the users table in Listing 61) We can choose any migration name we want, but it s convenient to end the name with _to_users, since in this case Rails can automatically construct a migration to add columns to the users table Moreover, by including the second argument, we ve given Rails enough information to construct the entire migration for us, as seen in Listing 74

class AddPasswordToUsers < ActiveRecord::Migration def selfup add_column :users, :encrypted_password, :string end def selfdown remove_column :users, :encrypted_password end end

This code uses the add_column method to add an encrypted_password column to the users table (and the complementary remove_column method to remove it when migrating down) The result is the data model shown in Figure 72 Now if we run the migration and prepare the test database, the test should pass, since the User model will respond to the encrypted_password attribute (Be sure to close any Rails consoles started in a sandbox; the sandbox locks the database and prevents the migration from going through)

Of course, we can run the full test suite with rspec spec/, but sometimes it s convenient to run just one RSpec example, which we can do with the -e ( example ) flag:

$ rspec spec/models/user_specrb \ > -e "should have an encrypted password attribute" 1 example, 0 failures