BDD는 테스트 케이스를 먼저 작성하고 실제 동작 코드를 나중에 작성하는 TDD에서 한발 더 나아가 테스트 케이스 자체가 요구사양이 되도록 하는 개발 방식이다. 테스트케이스가 사양과 일체화 됨으로서 , 사양작성 -> 코딩 -> 테스트 라는 일련의 흐름이 테스트케이스작성 작업을 중심으로 자연스럽게 구현된다.
.jpg) |
| The Behavior-Driven Development Cycle (출전: MSDN) |
TDD를 정착시킨 개발현장에서는 테스트 코드의 가독성을 높이고 JavaDoc과 같은 API문서 생성 프레임워크를 이용하여 테스트에서 프로그램에 기대하는 움직임을 기술함 으로서 테스트케이스가 상세설계서를 대체 할 수 있도록 하는 움직임이 있어 왔는데, BDD는 이것을 결합테스트와 시나리오 테스트까지 확장하여 각각에 해당하는 사양문서를 대체한다.
사양 전체를 테스트 케이스에 포함시키기 위해서는 메소드 중심의 Unit Test 뿐만 아니라 어플리케이션의 동작을 기술하는 스토리 프레임워크와 오브젝트의 동작을 기술하는 스펙프레임워크를 필요로 하게 되는데, 각각의 언어에서 BDD를 구현하기 위해 사용 할 수 있는 스토리/스펙 프레임워크는 다음과 같다.(출전: 위키피디아)
- RSpec - Ruby
- JBehave - Java
- NSpec - .Net
- GSpec - Groovy
- easyb - Groovy
- specs - Scala
- Specter - .NET
- dSpec - Delphi
- JSSpec - JavaScript
- PHPSpec - PHP
- Instinct - Java
- JDave - Java
- beanSpec - Java
- CSpec - C
- Tumbler - Java
- XSpec - XPath, XSLT, XQuery
- PySpec - Python
- Kiwi - Objective-C
도메인 주도 개발(domain driven design; DDD)과의 궁함
BDD는 2003년 Dan North에 의해 처음 개념이 언급되었고 이후 TDD지지자들의 성원속에 스토리(시나리오)테스트의 자동화라는 형태로 지원 프레임워크가 속속 등장하게 된다.BDD는 특히 자동화 테스트를 중요하게 생각하는 애자일개발과 오브젝트 지향 프로그래밍의 본질을 추구하는 도메인 주도 개발과의 궁합이 매우 좋다.
트랜젝션 스크립트 패턴 중심의 개발에서 결합테스트나 시나리오 테스트를 하기위해서는 결국 바운더리 인터페이스를 이용해야만 하는 경우가 많다. 즉, 웹 어플리케이션의 경우 화면을 테스터가 직접 조작하거나 HTTP레벨에서 이를 시뮬레이션해 주는 JMeter와 같은 툴을 사용하는 형태로 시나리오 테스트가 진행되는 경우가 많은데, DDD의 경우 도메인 오브젝트가 바운더리와 분리되어 있기 때문에 스토리/스펙 테스트가 보다 용이해 지는것이다.
BDD개발 프로세스
BDD의 핵심 개념은 사양이 바로 동작하는 테스트케이스(또는 시나리오)가 된다는 점 인데, 기술에 문외한인 이해관계자stakeholders도 테스트케이스로 작성된 사양을 작성하거나 읽을수 있어야 한다.일반적으로 BDD에 기반한 개발은 다음과 같은 프로세스를 거치게 된다.
- 비전을 달성하기 위해 각각 다른 프로젝트 이해관계자들이 공유할 수 있는 골을 설정한다.
- 골을 달성하기 위한 기능들을 그려낸다.
- 이해관계자를 포함해서 소프트웨어의 외형을 구현한다.
- 구현된 외형을 이용하여 어플리케이션의 동작을 묘사한다.
- 동작 시나리오를 작성한다.
- 스토리 내부의 단위 테스트를 작성한다.
- 프로그램 구현(Mock 포함)
- 단위테스트를 실행한다.
- 스토리 테스트를 실행한다.
스토리 테스트 작성시 주의해야 할 점은 유닛 테스트와 마찬가지로 반드시 모든 테스트가 실패하는것을 확인해 주어야 한다. 이를 불필요한 과정으로 인식하고 넘어가는 경우, 잘못 작성된 코드도 성공해 버리는 테스트 불량을 검출할 수 없게 된다.
댓글 없음:
댓글 쓰기