User Validations

The User model we created in Section 6.1 now has working name and email attributes, but they are completely generic: Any string (including an empty one) is currently valid in either case. And yet, names and email addresses are more specific than this. For example, name should be non-blank, and email should match the specific format characteristic of email addresses. Moreover, since we’ll be using email addresses as unique usernames when users sign in, we shouldn’t allow email duplicates in the database.

                 In short, we shouldn’t allow name and email to be just any strings; we should enforce certain constraints on their values. Active Record allows us to impose such constraints using validations. In this section, we’ll cover several of the most common cases, validating presence, length, format, and uniqueness. In Section 6.3.4 we’ll add a final common validation, confirmation. And we’ll see in Section 7.3 how validations give us convenient error messages when users make submissions that violate them.

  Initial User Tests

As with the other features of our sample app, we’ll add User model validations using test-driven development. Because we didn’t pass the

--no-test-framework

flag when we generated the User model (unlike, e.g., Listing 5.28), the command in Listing 6.1 produces an initial spec for testing users, but in this case it’s practically blank (Listing 6.7).

This simply uses the pending method to indicate that we should fill the spec with something useful. We can see its effect by running the User model spec:

On many systems, pending specs will be displayed in yellow to indicate that they are in between passing (green) and failing (red).
       We’ll follow the advice of the default spec by filling it in with some RSpec examples,  shown in Listing 6.8. 

The before block, which we saw in Listing 5.27, runs the code inside the block before each example—in this case, creating a new @user instance variable using User.new and a valid initialization hash. Then

makes @user the default subject of the test example, as seen before in the context of the page variable in Section 5.3.4.  

             The two examples in Listing 6.8 test for the existence of name and email attributes:

These examples implicitly use 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:

(Recall from Section 4.2.3 that Ruby uses a question mark to indicate such true/false boolean methods.) The tests themselves rely on the boolean convention used by RSpec: the code  

  can be tested using the RSpec code

Because of subject { @user }, we can leave off