Ruby On Rails Classroom image

Pooja  Negi / Student / Web Technology

To post your Question Join Classroom
Lesson Topics's No:-  |1 | 2|Last
Lessons:-User Validations

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


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:


$ bundle exec rspec spec/models/user spec.rb
Finished in 0.01999 seconds
1 example, 0 failures, 1 pending
               User add some examples to (or delete)
                /Users/mhartl/rails projects/sample app/spec/models/user spec.rb
               (Not Yet Implemented)


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 and a valid initialization hash. Then

subject  {  @user  }


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:


it { should respond to(:name) }
it { should respond to(:email)


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:

$ rails console --sandbox
>> user =
>> user.respond to?(:name)
=> true
>> user.respond to? (:foobar)
=> false 


(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  

@user. respond to?(:name)


  can be tested using the RSpec code

@user.should respond to(:name)


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

@user in the test, yielding it { should respond to  (: name) }  
Pooja   Negi

Skills    Ruby On Rails

Qualifications :- High School - SSN high school, College/University - HNBGU, College/University - SRHU,
Location :-Ranipokhari,Rishikesh,Uttarakhand,India
Description:- Student

  Students (0)