Question

I think this is as much a programming practice question as it is a technical question.

I am doing the Ruby on Rails Tutorial and am up to the Chapter 7 Exercises, question 2. This question asks you to write tests that verify the error messages for an invalid user appear on the reloaded signup page (eg blank password, invalid email address).

I have some code that works fine enough but I don’t feel I’m actually testing anything. I have simply tested for the presence of the error messages that appeared when I manually entered a blank user into the signup page. Unsurprisingly, the tests pass – I simply copied and pasted the error messages into the tests!

The relevant part of my user_pages_spec.rb are:

describe "signup" do

before { visit signup_path }

let(:submit) { "Create my account" }

describe "with invalid information" do
  it "should not create a user" do
    expect { click_button submit }.not_to change(User, :count)
  end
  describe "after submission" do
    before { click_button submit }
    it { should have_selector('title',text: 'Sign up') }
    it { should have_content('error') } 
    it { should have_content('Password digest can\'t be blank') }
    it { should have_content('Name can\'t be blank') }
    it { should have_content('Email can\'t be blank') }
    it { should have_content('Email is invalid') }
    it { should have_content('Password can\'t be blank') }
    it { should have_content('Password is too short (minimum is 6 characters)') }
    it { should have_content('Password confirmation can\'t be blank') }
  end
end

Is this the right way to do it?
Shouldn’t I be getting Ruby to tell me what the error messages / translations are, and testing those?
What happens if I change one of my validation conditions, like password length?
Similarly, when I fix the error message about Password Digest, should I have to change my testing file?

Edit: What if I don’t know what the exact error string will be? Shouldn’t Ruby tell the test what the error message will be? Should I be using ‘have(x).errors_on’ for this?.

Answer 1

You could always expand the tests to where you would test if an user were to insert an username but not a password, check the results, etc. I think that would be overkill though. Other than that, I think you are fine.

If you were to change your error messages, then you would have to change the tests. But let’s think of how TDD works. You write the test, then you write your code, then refactor if need be. So ideally, you would already know what your validation conditions were. If you wanted to change your code later on, then you would change your tests, then your code.

From the Ruby on Rails Guide on Testing:

Ideally, you would like to include a test for everything which could possibly break. It’s 
a good practice to have at least one test for each of your validations and at least one 
test for every method in your model.

We can extend this not to just to models, but also to your controllers, routing, etc. In other words, test what your code is doing. For example, if you set it up where an user see’s a flash message when they sign in, then test to make sure the user see’s that flash message. If the user did something wrong and should see a different flash message, then test to make sure they got the different flash message.

I would consider after you finish Hartl’s tutorial checking out shoulda matchers.

Here is a short readme on rspec best practices.

Finally, Wolfram Arnold’s Six Part tutorial series is helpful in learning what to test for, although it’s a little outdated.

EDIT: You will have to write in your test the error message Rails has pre-written, unless of course you wrote a custom message. Thankfully you can find the pre-written errors within the Ruby internationalization or Ruby l18n for short. Here is the list of expected messages:

  inclusion: "is not included in the list"
  exclusion: "is reserved"
  invalid: "is invalid"
  confirmation: "doesn't match confirmation"
  accepted: "must be accepted"
  empty: "can't be empty"
  blank: "can't be blank"
  too_long: "is too long (maximum is %{count} characters)"
  too_short: "is too short (minimum is %{count} characters)"
  wrong_length: "is the wrong length (should be %{count} characters)"
  not_a_number: "is not a number"
  not_an_integer: "must be an integer"
  greater_than: "must be greater than %{count}"
  greater_than_or_equal_to: "must be greater than or equal to %{count}"
  equal_to: "must be equal to %{count}"
  less_than: "must be less than %{count}"
  less_than_or_equal_to: "must be less than or equal to %{count}"
  odd: "must be odd"
  even: "must be even"

Insert the attribute that you are validating into the beginning of the error message above into your test and voila, that is the error message you should expect from Rails.

And finally, have(x).errors_on is one way you can test for the flash message. Shoulda matchers also has a relevant page devoted to flash message tests. Anything extra I think would be overkill.