In the present case, we use it to set both password attributes to " ":

We also want to ensure that the password and confirmation match. The case where they do match is already covered by it { should be_valid }, so we only need to test the case of a mismatch: 

In principle, we are now done, but there is one case that doesn’t quite work. What if the password confirmation is blank? If it is empty or consist of whitespace but the password is valid, then the two don’t match and the confirmation validation will catch it. If both the password and its confirmation areempty or consist of whitespace, then the password presence validation will catch it. Unfortunately, there’s one more possibility, which is that the password confirmation is nil. This can never happen through the web, but it can at the console:

When the confirmation is nil, Rails doesn’t run the confirmation validation, which means that we can create users at the console without password confirmations. (Of course, right now we haven’t added the validations yet, so the code above will work in any case.) To prevent this, we’ll add a test to catch this case:

(This behavior strikes me as a minor bug in Rails, and perhaps it will be fixed in a future version, and in any case adding the validation does no harm.)

               Putting everything together gives the (failing) tests in Listing 6.28. We’ll get them to pass in Section 6.3.4.