rspec에서 가입 검증을 테스트하는 방법은 무엇입니까? (레일 튜토리얼 챕터 7 연습)

Question

이것은 기술적 인 질문만큼 프로그래밍 연습 문제라고 생각합니다.

Ruby on Rails 튜토리얼을 읽고 있는데 질문 2 인 Chapter 7 Exercises까지입니다.이 질문은 유효하지 않은 사용자의 오류 메시지가 다시로드 된 가입 페이지에 표시되는지 확인하는 테스트를 작성하도록 요청합니다 (예 : 빈 암호, 유효하지 않은 이메일 주소).

나는 충분히 잘 작동 몇 가지 코드를 가지고 있지만 실제로 무엇을 테스트하고 있습니다 생각하지 않습니다. 로그인 페이지에 빈 사용자를 수동으로 입력했을 때 나타나는 오류 메시지의 존재 여부를 간단히 테스트했습니다. 당연히 테스트가 통과합니다. 단순히 오류 메시지를 복사하여 테스트에 붙여 넣었습니다!

의 관련 부분 내 user_pages_spec.rb 있습니다

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 

이 그것을 할 올바른 방법인가? 오류 메시지/번역이 무엇인지 Ruby에 알려주지 않아야합니까? 암호 길이와 같은 유효성 검사 조건 중 하나를 변경하면 어떻게됩니까? 마찬가지로 암호 다이제스트에 대한 오류 메시지를 수정하면 테스트 파일을 변경해야합니까?

편집 : 내가 정확한 오류 문자열이 될 것입니다 무엇 무엇을 모른다면? Ruby가 테스트에 오류 메시지를 알려주지 않아야합니까? 'have (x) .errors_on'을 사용해야합니까?. 사용자가 사용자 이름이 아닌 암호를 삽입한다면

Answer 1

당신은 항상 내가 그 생각 잔인한 것 같아 등의 결과를 확인, 테스트 할 위치로 테스트를 확장 할 수있다. 그 외에는 괜찮다고 생각합니다.

오류 메시지를 변경하려면 테스트를 변경해야합니다. 그러나 TDD가 어떻게 작동하는지 생각해 봅시다. 테스트를 작성한 다음 필요에 따라 코드를 작성한 다음 리팩터링을 작성합니다. 이상적으로, 당신은 이미 귀하의 유효성 확인 조건이 무엇인지 알 것입니다. 나중에 코드를 변경하려면 테스트를 변경 한 다음 코드를 변경하십시오. 테스트에 레일 가이드에 루비에서

:

코드가 무엇을하고 있는지 우리는뿐만 단지 모델뿐만 아니라, 즉 등 당신의 컨트롤러, 라우팅, 시험이를 확장 할 수 있습니다

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. 

. 예를 들어 사용자가 로그인 할 때 플래시 메시지가 표시되는 위치를 설정 한 경우 사용자에게 해당 플래시 메시지가 표시되는지 테스트합니다. 사용자가 잘못하여 다른 플래시 메시지가 표시되면 다른 플래시 메시지가 있는지 테스트합니다. 당신이있는 Hartl의 튜토리얼 shoulda 매처 (matcher) 체크 아웃 마친 후 나는 고려할 것

.

여기 RSpec에 모범 사례에 관한 짧은 readme이다.

마지막으로, Wolfram Arnold의 Six Part tutorial 시리즈는 약간 구식이지만 테스트 할 내용을 학습하는 데 도움이됩니다.

편집 : 당신은 사용자 정의 메시지를 작성 물론하지 않는 한 오류 메시지 레일이 작성한 사전했다 테스트에 작성해야합니다.고맙게도 Ruby internationalization 또는 Ruby l18n의 사전 오류를 찾을 수 있습니다. 여기에 예상되는 메시지의 목록입니다

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" 

당신이 위의 테스트 및 짜잔에 오류 메시지의 시작 부분에 유효성을 검사 속성을 삽입, 그건 당신이 레일에서 기대해야하는 오류 메시지입니다.

그리고 마지막으로 have(x).errors_on은 플래시 메시지를 테스트 할 수있는 한 가지 방법입니다. Shoulda matchers는 또한 관련 메시지를 플래시 메시지 tests에 바칩니다. 내가 과잉이라고 생각하는 것 이상의 여분.