node.js의 test framework을 공부하다보니 낯선 BDD라는 용어가 등장했다. 예를 들어 유명한 mocha test framework은 TDD와 BDD를 지원하고, vows는 BDD를 지원한다고 한다. 이렇게 되면 BDD에 대해 공부해야 하는 상황. 그런데 BDD라는 용어를 가장 먼저 사용한 Dan North의 글 (한글 번역)이나 wikipedia의 글을 읽어봐도 모호하기만 했다.
여러 가지 자료를 찾아보고, infoq에서 진행한 Dan North를 포함한 몇 명의 Agile 전문가가 참여한 패널 토의를 읽어 보고 나서야 비로서 대강 BDD와 TDD의 차이를 나의 관점으로 이해하게 되었다.
이해한 내용을 간단히 정리하자면 아래와 같다.
1.Test-Driven Development의 용어로 인한 오해가 있다.
Test-Driven Development의 'Test'가 의미하는 바는 Verification(검증)이 아닌 Specification(요구사항 명세)에 가깝다. 즉, 테스트 케이스를 먼저 작성하고 코딩하는 것은 '요구사항 명세'를 개발자 관점에서 수행하는 것이다.
그럼에도 불구하고 'Test'라고 하면 쉽게 떠올리는 검증이라는 이미지로 인해, 아래와 같은 오해가 생긴다.
- 테스트 케이스는 개발자가 아닌 Tester에 의해 작성되는 것이라는 오해(TDD를 수행하는 개발자 조차)
- 테스트를 수행한다거나, 테스트 케이스를 작성한다고 하면, 개발 막바지라고 생각하는 오해(Waterfall 스타일에 익숙한 개발자, 매니저, 테스터, 고객)
- Acceptance 테스트에는 TDD가 사용되지 않는다는 오해
위의 오해를 피하기 위해 TDD와 TDD에서 사용하는 용어의 재 정의가 필요하다. 그것이 Behavior-Driven Development이다.
2. BDD는 TDD의 일종이다. 단지 TDD를 더 제대로 수행하기 위한 장치를 한 것이다.
TDD의 'T'가 의미하는 바가 Specification이라면, BDD의 'B'가 의미하는 바와 같다. 그런데, TDD는 요구사항보다 함수 검증에 집중되는 경향이 있고 BDD는 좀 더 요구사항에 집중한다. 예를 들어 TDD를 수행한다고 하면, 고객 요구사항이 아닌 내부 함수 테스트를 수행하는 경우도 흔하다. 이것은 TDD를 제대로 이해하지 않아서 생기는 문제이다. 그래서, BDD는 테스트 케이스의 명세나 툴을 통해 의도적으로 개발자에게 요구사항에 집중하도록 한다.
위와 같이 BDD와 TDD는 사실 다르지 않다. 이 내용을 정확히 이해한다면 TDD를 지원하는 test framework으로도 BDD를 수행할 수 있고, 반대로 정확히 이해하지 못한다면 BDD를 지원하는 test framework으로 흔히 하는 TDD 실수를 똑같이 저지를 수 있는 것이다. TDD를 제대로 수행하고 있다면, BDD를 지원하는 test framework을 굳이 사용하지 않아도 상관없다.
참조
1. Dan North의 BDD 소개글: http://dannorth.net/introducing-bdd/
2. Dan North의 BDD 소개글 번역: http://blog.jaigurudevaom.net/319
3. InfoQ의 Panel 토의: http://www.infoq.com/articles/virtual-panel-tdd-bdd
4. 마틴 파울러의 "Mocks aren't stubs" : http://martinfowler.com/articles/mocksArentStubs.html
댓글 없음:
댓글 쓰기