2011-10-19 1 views
0

저는 rspec에 매우 익숙하며, 실제로 생성 된 객체가 존재하는지 확인하기위한 테스트를 작성하려고합니다. 이 시점에서 거부 할 수rSpec 객체를 만들 수 있는지 확인하십시오.

1) UserService.new should create a UserService object 
    Failure/Error: service = UserService.new 
    Errno::ECONNREFUSED: 
     Connection refused - connect(2) 
    # ./spec/requests/user_service_spec.rb:6:in `new' 
    # ./spec/requests/user_service_spec.rb:6:in `block (3 levels) in <top (required)>' 

내가 연결을 기대 해요 : 내가 테스트를 실행할 때

require 'spec_helper' 

describe "UserService" do 
    describe ".new" do 
    it "should create a UserService object" do 
     service = UserService.new 
     service.should_not be_nil 
    end 
    end 
end 

문제는, 내가이 출력을 받고 있어요 : 여기 지금처럼 내 테스트 모습입니다 , 테스트 대신 테스트를 어떻게 할 수 있습니까? 아니면 정확한 결과물을 볼 수 있습니까? 감사!

+1

'UserService' *가 무엇인지에 대한 자세한 정보가 필요합니다. 어딘가에 연결되는 이유는 무엇입니까? –

+0

정말 관련이 있는지 잘 모르겠습니다. 내가 테스트하고 싶은 것은 연결에 성공했는지 확인하는 것입니다. 그것은 서비스가 실제로 무엇을 하든지 관계없이 모든 것에 적용되어야합니다. 내가 왜 연결이 실패하고, 그것에 대한 수정을 알고 있지만, 그 상황 (어디 연결할 수없는)에 대한 테스트 실패를 올바르게 수행하는 방법을 테스트하려고 해요. –

+0

당신은 예외 테스트 방법을 묻고 있습니까 rSpec 즉, 테스트에서 예외가 예상되며 예외가 발생하면 테스트가 성공한 것입니다. – leenasn

답변

1

두 가지 문제점이 있습니다. 먼저 테스트에서 외부 서비스에 실제로 연결하려고합니다. 일반적으로 여러분은 테스트 대상의 객체에 여러분이 정상적으로 연결하는 서비스를 나타내는 모의 (mock)을 제공하기를 원합니다. 귀하의 질문과 의견에 귀하의 코드가 작동하려면 다음과 같이 변경해야합니다 :

실제 서비스를 "숨기려면"외관이나 프록시 개체를 만들어야합니다 귀하의 UserService 개체에서. 이 객체는 기본적으로 기본 서비스를 일대일로 매핑해야합니다. 그 이유는 내부 서비스가 외부 서비스에 밀접하게 연결되기를 원하지 않는다는 것입니다. 사용자가 내부 서비스에 묶여 있기를 바랄뿐입니다. 정면은 단위 테스트를 받아서는 안되며, 현재의 위치로 돌아갈 수 있으며 비즈니스 논리가 없으므로 단위 테스트를 받아서는 안됩니다.

두 번째로 종속 종속 버전을 사용하면 UserService 개체를 특정 기본 서비스 구현과 분리 할 수 ​​있습니다. UserServices 생성자가 객체, 객체 및 호출 메소드를 사용하여 서비스 관련 작업을 수행하기를 원합니다. UserService는 실제 서비스 인 경우 더 이상 신경 쓰지 않으므로 테스트 도중 간단한 스텁을 제공 할 수 있으며 외부 서비스가 느려지거나 다른 방식으로 중단 될 때 테스트를 중단 할 필요가 없습니다. 예기치 않게 작동합니다.

두 번째는 should_not raise_error을 사용하여 테스트에서 특정 사례를 무시한 것입니다. should_not raise_error(ConnectionError)과 같은 지정된 오류와 함께 사용하면 문제가 없지만 사용자가 구출 할 수 없을 때 오류를 던지면 정상적으로 수행되므로 나중에이 동작을 추가해야하는 경우 테스트가 중단되지 않습니다.

UserService.new()을 호출 할 때 UserService 개체를 다시 가져와야한다고 말합니다.이 경우 제대로 테스트하지 않고 예상되는 동작을 문서화하기 위해 수행해야 할 작업은 피드입니다 그것은 당신이 지금 가지고 같은 두 번째 테스트 생성 테스트에서 작동 모형 :로 시작하는이 상황에서 끝나지하는 방법에 그냥 몇 가지 생각

describe ".new" do 
    it "when service is down should throw error" do 
    UserService.new(offline_mock).should raise_error(ConnectionError) 
    end 
end 

을, 테스트에서 문제가 일반적으로 평소와 같이) 건축 문제의 징후.