메뉴 바로가기 검색 및 카테고리 바로가기 본문 바로가기

한빛출판네트워크

한빛랩스 - 지식에 가능성을 머지하다 / 강의 콘텐츠 무료로 수강하시고 피드백을 남겨주세요. ▶︎

IT/모바일

Behavior Driven Development Using Ruby (Part 3) - (4)

한빛미디어

|

2007-12-24

|

by HANBIT

10,289

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

Test::Unit에서 test/spec을 이용해 BDD 사용하기

여태까지 RSpec을 중심으로 모든 것을 설명해 왔었고, 여기에는 RSpec이 처음 시작하는 여러분에게 좋은 툴이 될 것이기 때문이라는 이유도 있었다. 여러분이 보았듯이 RSpec은 루비의 Test::Unit이 그러하듯이 RCov, Heckle과 아주 잘 연동되고 있으며, 괜찮은 위임(Mocking) 프레임웍 또한 제공하고 있고 확장성에 대한 여지까지도 남겨두고 있다.

그러나 여기서 한 가지 말해야 할 것이 있다 : 루비의 Test::Unit은 기본 배포본에 포함되어 있지만 RSpec은 그렇지가 않다. 이것이 의미하는 바가 무엇이냐 하면 RSpec과 호환이 잘 되지 않는 굉장히 많은 테스트 코드와 헬퍼 코드와 확장 코드가 존재한다는 것이고, 이러한 것들과의 호환성을 맞추는데는 굉장히 많은 시간이 소요된다는 것이다.

여러분의 프로젝트에서 Test::Unit을 계속해서 유지해야 하지만, BDD의 친근한 문법과 구성을 RSpec을 이용하여 사용하고 싶다면 Christian Neukirchen의 test/spec을 이용해 보는 것이 좋을 것 같다.

사실 이 우리의 Dots::Grid에 대한 RSpec 코드 를 보면 아주 간단한 수정만으로도 test/spec을 이용해서 작동시킬 수 있다는 것을 알 수 있다.
grid_spec.rb (converted to test/spec) 
describe "An empty dots grid" do                                  

  # all else the same

  it "should throw an error when connecting non-adjacent dots" do        
    # === RSpec Style ===
    #lambda { @grid.connect([0,0],[0,5]) }.should raise_error(Dots::InvalidEdgeError) 

    # === test/spec style ===
    should.raise(Dots::InvalidEdgeError) {
      @grid.connect([0,0],[0,5])
    }
  end  

end

describe "A drawn on dots grid" do  

  # all else the same

  it "should return a set with a box when connect() completes one box" do  
    result = @grid.connect [1,1], [1,0]
    result.size.should == 1
    result.each do |b|         

      # === RSpec Style ===
      #b.should be_an_instance_of(Dots::Box)   

      # === test/spec Style ===
      b.should.be.an.instance_of?(Dots::Box) 

    end   
  end 

  it "should return a set of two boxes when connect() completes two boxes" do
    @grid.connect [1,0], [2,0]
    @grid.connect [2,0], [2,1]
    @grid.connect [2,1], [1,1]      

    result = @grid.connect [1,1], [1,0]

    result.size.should == 2

    result.each do |b|         

      # === RSpec Style ===
      #b.should be_an_instance_of(Dots::Box)   

      # === test/spec Style ===
      b.should.be.an.instance_of?(Dots::Box) 

    end 

  end    

end
프레임웍을 변경했음에도 기본적은 부분은 그대로 남아 있다는 것을 볼 수 있다. 기본적인 차이점은 test/spec은 Test::Unit의 위에 구현이 된 것으로서 기존의 TDD 코드와 병합하여 사용할 수 있도록 한 것이다. 여러분이 이미 assert_* 로 시작하는 헬퍼 코드들을 만들어 놓았다면 이 프레임웍에서 마음껏 사용할 수 있다. 그리고 기존과 마찬가지로 테스트 러너(test runners)도 원하는 대로 사용이 가능하다.

test/spec이 스펙 문서 생성과 같은 RSpec에 있는 작은 기능까지도 포함하고 있지만, 우리가 필요한 모든 것을 다 포함하고 있지는 않다. 그래서 없는 부분은 다른 곳에서 가져와서 연동시켜 사용해야 하는데, 예를 들면 위임(Mocking) 프레임웍을 사용하고자 한다면 FlexMock이나 Mocha와 같은 것을 다운받아서 사용해야 한다. 그렇지만 RSpec을 꼭 사용해야만 한다면 test/spec이 가장 최선의 선택일 것이라고 생각한다.

실전으로

여태까지 길었던 BDD에 대한 글이 여러분에게 도움이 되었을 것이라고 생각한다. 물론 여태까지의 글에서 여러분이 BDD를 이용하기 위해서 중요한 부분들에 대해서 설명했다고 생각하지만, 아마도 BDD에 숨겨져 있는 원칙들에 대해서 더 많은 것을 알고 싶어할 것이라고 생각한다. 이러한 궁금증을 해소하고자 하는 독자는 다음의 behaviour-driven.org 에 있는 정보를 이용해 보면 좋을 것이다. 물론 블로그 스피어에서도 정보를 얻을 수 있다.

물론 가장 정확하게 이해할 수 있는 방법은 프로젝트에서 실제로 사용해보면서 작동하는 방식에 대해서 깨우치는 것일 거라고 생각한다. 필자는 독자 여러분이 이 글에서 배운 것을 이용하면서 더 많은 깨우침을 얻기를 바란다.


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

최근 본 상품0