한빛출판네트워크

제공 : 한빛 네트워크
저자 : Gregory Brown
역자 : 노재현
원문 : Behavior Driven Development Using Ruby (Part 3)

RSpec의 기본이라는 글을 시작으로 세 파트로 이루어진 이 글을 시작했었다. 지금까지 배웠던 프레임웍으로 지난 시간에는 BDD를 이용하여 간단한 애플리케이션을 개발하기 위한 실질적인 예제도 살펴보았다. 또 스펙을 먼저 작성하고 나서 만들어진 스펙을 이용하여 디자인을 이끌어내면 결과적으로 깔끔하고 좋은 코드를 작성할 수 있다는 것도 배웠다.

물론 이것 보다도 더 복잡한 요청사항을 처리하고자 한다면 더 많은 고급 기능들의 도움을 받아야할 것인데, 이번 글에서는 RSpec의 고급 기능들에 대해서 알아보고 그 외에 유용한 툴들에 대해서도 다뤄보도록 하겠다.

이 글에서는 두 번째 파트에서 사용된 예제의 소스 코드를 기반 코드로 사용하려고 한다. 이제부터는 스펙에 대해서 좀 더 집중해서 설명할 것이니 코드의 구현에 관한 자세한 내용은 이전 글을 참고하기 바란다.

화이트 보드에 기록한 스펙을 텍스트 편집기로 가져오자

필자는 보통 유닛 테스트 코드를 작성할 때 flunk 코드를 먼저 작성하고는 한다. 이렇게 해서 나중에 해당 코드를 구현해야 한다는 것을 되새길 수 있기 때문이다. 보통 다음과 같이 작성한다.

class UserTest < Test::Unit::TestCase    

  def test_user_should_have_valid_email_address  
     flunk "write test verifying user"s email address" 
  end

end

이 코드는 다음과 같은 에러를 출력한다.

  1) Failure:
test_user_should_have_valid_email_address:5
write test verifying user"s email address.

정확하게 작동하기는 하지만 원하는대로 작동하지는 않고 있다. RSpec은 좀 더 나은 방법으로 처리하고 있는데, 바로 자동적으로 비어있는 예제를 찾으면 아직 구현되지 않은 것으로 분류한다. 그러므로 위와 같은 기능을 다음과 같이 구현할 수 있다.

describe "user" do    
  it "should have a valid email address" 
end

결과는 다음과 같다.

Finished in 0.03517 seconds

1 example, 0 failures, 1 pending

Pending:
user should have a valid email address (Not Yet Implemented)

그럼 이 점을 유념하고 몇 주전에 기반 코드를 작성할 때 테스트 되지 않은 상태로 넣었던 유저 인터페이스에 어떠한 테스트가 필요한지를 알아보도록 하자.

spec/interface_spec.rb

require File.join(File.expand_path(File.dirname(__FILE__)),"helper")
require "#{LIB_DIR}/interface"

describe "An interface" do

  it "should prompt for players"

  it "should prompt for grid size"

  it "should be able to update board display"

  it "should display a score board"

  it "should prompt for a players move"

end 

이제 이 코드를 실행하면 다음과 같은 결과를 볼 수 있다.

PPPPP

Finished in 0.010666 seconds

5 examples, 0 failures, 5 pending

Pending:
An interface should prompt for players (Not Yet Implemented)
An interface should prompt for grid size (Not Yet Implemented)
An interface should be able to update board display (Not Yet Implemented)
An interface should display a score board (Not Yet Implemented)
An interface should prompt for a players move (Not Yet Implemented)

아직 구현되지 않은 부분에 대해서 출력해 주고 있는 것을 볼 수 있다. 이렇게 구현해야 할 사항들에 대해서 기록해 주면 스펙을 작성하는데에도 많은 도움이 된다.

버그 트랙킹 시스템에 있는 버그 레포트를 Spec으로 가져오자

개발자들중에는 일부는 실패한 테스트를 포함한 코드를 체크인하는 경우가 있다. 프로젝트마다 다르겠지만 이렇게 실패한 테스트를 포함한 코드가 개발 코드에 포함되어서는 안되는 일이다. 최소한 주석 처리만이라도 해서 체크인을 해야한다.

하지만 이런 방식은 위험하다. 이렇게 처리하고 나면 나중에 잊어버릴 수도 있기 때문이다. RSpec은 이것을 더 효율적인 방법으로 처리한다. 실패 메시지를 숨겨줄 뿐만 아니라 결과 보고에는 이 부분에 대해서 알려주는 기능을 포함하고 있다.

어떻게 작동하는지 다음 코드를 보자.

describe "the answer" do 

  before :each do
    @answer = 0
  end 

  it "should be 42" do
    pending("We need to wait 7.5 million years") do
      @answer.should == 42
    end
  end

end

이 코드를 실행하고 나면 결과 보고는 다음과 같이 나오게 된다.

P

Finished in 0.037488 seconds

1 example, 0 failures, 1 pending

Pending:
the answer should be 42 (We need to wait 7.5 million years)

재밌는 것은 나중에 누군가가 이 문제를 해결하게 되면, 위의 결과가 실패로 변하게 된다는 것이다. 예를 들어 설정을 @answer = 42 와 같이 변경을 하게 된다면 다음과 같은 결과가 나온다.

F

1)
"the answer should be 42" FIXED
Expected pending "We need to wait 7.5 million years" to fail. No Error was raised.
/Users/sandal/Desktop/foo.rb:11:
/Users/sandal/Desktop/foo.rb:4:

Finished in 0.034342 seconds

1 example, 1 failure

예제가 성공적으로 고쳐지게 되면 실패했다는 결과가 발생하게 되고, 이걸 보고 pending()을 이제 지울 수가 있겠구나 라는 생각을 할 수 있도록 해준다. 물론 이런 방식을 불필요하게 많이 사용하는 건 좋은 방법이 아니지만, 그저 주석처리로 처리해 놓은 후에 나중에 잃어버리고 처리하지 못하는 것에 비하면 괜찮은 방법이라고 할 수 있다.

---

역자 노재현님은 어렸을 때부터 컴퓨터를 접하게 된 덕에 프로그래밍을 오랫동안 정겹게 하고 있는 프로그래머 입니다. 특히나 게임 및 OS 개발에 관심이 많으며, 심심할 때면 뭔가 새로운 프로그램을 만들어내는 것을 좋아합니다. 다음에서 웹 관련 개발을 한 후에 현재는 www.osguru.net이라는 OS관련 웹사이트를 운영하며 넥슨에서 게임 개발을 하고 있습니다.
* e-mail: wonbear@gmail.com
* homepage: http://www.oguru.net