티스토리 뷰

Test::Unit 프레임워크의 기능

1) 개별테스트를 표현하는 방법을 제공한다.

2) 테스트를 구조화하는 프레임워크를 제공한다.

3) 테스트를 수행하기 위한 유연한 방법을 제공한다.



단언문 assert


사용 이유   

1) 테스트 안에서 개별적인 if문들을 여러개 길게 늘어 놓지 않기 위해서

2) 각 단언문은 기대되는 결과를 적을 수 있는 방법과 실제 결과를 전달하는 방법 제공




RSpec 프레임워크


RSpec 프레임워크 :  BDD 프로세스에서 사용하는 툴


BDD란? : 어플리케이션의 개발과정을 확인하는 사람이 읽을 수 있는 명세서를 적는 일

--> 그렇게 때문에 테스트 코드에 자세한 설명이 첨부되어 있다.



1. describe  함수를 설명하는 방법


describe 키워드를 사용해서 어떤 함수를 설명하려는지 명확하게 해야합니다. 예를 들어서, 클래스 함수를 참조할 때는 .(또는 ::)를 접두어로, 인스턴스 함수를 참조할 때는 #를 접두어로 사용한다.


[좋은 예시]

describe '.authenticate' do 

describe '#admin?' do 




2. 설명을 짧게 유지하기

명세의 설명은 40문자를 넘으면 안됩니다. 40문자를 넘을 때는 context를 사용해 쪼개야 한다.


[나쁜 예시]

it 'has 422 status code if an unexpected params will be added' do


[좋은 예시]

context 'when not valid' do it { is_expected.to respond_with 422 } end


예제에서 it {is_expected.to respond_with 422} 조건문으로 바꿈으로써 status 코드에 관한 설명을 제거 하였습니다. 



3. 단일 조건 테스트

'단일 조건'에 관한 팁은 '각 테스트는 한가지만 확인해야 한다'를 말합니다. 즉 에러를 찾을 때 도움이 되고, 실패하는 테스트를 바로 찾을수 있습니다.


같은 예제 안에서 여러 예상치가 나온다면 여러 행동으로 나누어야 한다는 신호입니다.


[좋은 예시 1 - 분리형]

it { is_expected.to respond_with_content_type(:json) } it { is_expected.to assign_to(:resource) }


[좋은 예시 2  - 통합형]

it 'creates a resource' do expect(response).to respond_with_content_type(:json) expect(response).to assign_to(:resource) end



4. 모든 가능한 케이스를 테스트하기


모든 케이스를 테스트하지 않으면 유용하지 않게 됩니다. 유효한 경우와 유효하지 않은 경우 모두를 테스트 해야합니다. 예를 들어 다음과 같은 destroy 액션이 있을 때


before_filter :find_owned_resources before_filter :find_resource def destroy render 'show' @consumption.destroy end


보통은 @consumption 인스턴스가 잘 삭제되어 있는지만을 확인한다. 하지만 이 상황에서는 2가지 케이스가 더 있다. 1) 리소스를 찾지 못했을 때, 2) 애초에 리소스를 소유하지 않았을 때. 이러한 모든 케이스를 가정하고 테스트 코드를 작성해야 합니다.


[나쁜 예시]

it 'shows the resource'


[좋은 예시]

describe '#destroy' do context 'when resource is found' do it 'responds with 200' it 'shows the resource' end context 'when resource is not found' do it 'responds with 404' end context 'when resource is not owned' do it 'responds with 404' end end


#destroy에 대한 메서드를 테스트 할 때, 3가지의 context가 존재한다.

1) when resource is found 

2) when resource is not found. 

3) when resource is not owned. 

이렇게 3가지의 경우가 있다.  it는 테스트 케이스의 결과값을 어떻게 응답할 것인가에 대한 것이다.



5. Expect vs Should 문법


새 프로젝트에서는 항상 expect 문법만 사용합니다.


[나쁜 예시]

it 'creates a resource' do response.should respond_with_content_type(:json) end



[좋은 예시]

it 'creates a resource' do expect(response).to respond_with_content_type(:json) end


[나쁜 예시]

context 'when not valid' do it { should respond_with 422 } end



[좋은 예시]

context 'when not valid' do it { is_expected.to respond_with 422 } end




6. Subject 사용하기


만약 같은 subject에 대해 여러 테스트를 하고 있다면, subject{}를 이용해 반복을 제거(DRY)합니다.


[나쁜 예시]

it { expect(assigns('message')).to match /it was born in Belville/ }



[좋은 예시]

subject { assigns('message') } it { is_expected.to match /it was born in Billville/ }


위의 나쁜 예시에서는 message에 관해서 테스트를 할 때 assigns('message')를 매번 작성해 주어야 한다. 하지만 좋은 예시에서는 assign('message')를 subject 블록 안에 포함하고 있기 때문에 중복해서 작성하지 않아도 된다.



7. let과 let! 사용하기

만약 before 인스턴스 변수를 만들지 않고 변수를 할당해야 한다면, let을 사용합니다. let 사용하면 변수를 테스트에서 처음 사용 될때만 lazy load하고 테스트 명세가 끝날 때까지 캐싱할 수 있다.

스택 오버플로우 글 링크



[나쁜 예시]

describe '#type_id' do before { @resource = FactoryGirl.create :device } before { @type = Type.find @resource.type_id } it 'sets the type_id field' do expect(@resource.type_id).to equal(@type.id) end end



[좋은 예시]

describe '#type_id' do let(:resource) { FactoryGirl.create :device } let(:type) { Type.find resource.type_id } it 'sets the type_id field' do expect(resource.type_id).to equal(type.id) end end


위의 예제에서 보면 변수를 할당하는 방법은 2가지가 있다. before와 let을 사용하는 것이다. before를 사용하게 되면 인스턴스 변수를 선언하고 객체를 할당한다. 반면에 let을 사용하면 lazy load를 하여서 테스트가 끝날 때까지 캐싱을 한다.

lazy load란?


























댓글