데이터 기술 동향 < 정보마당 - 한국데이터산업진흥원
오래도록 발전하는 개발자로 살아가기 입에 쓴 보약, TDD와 BDD 개발자로서 발전이 없다고 느껴질 때, 자신의 업무와 더불어 발전할 수 있는 방법이 있다. 바로 Test Driven Development(이하 TDD)와 Behavior
kdata.or.kr
TDD 란?
Test code 를 작성하고 이에 따라 검증된 code 를 실제 코드로 반영하는 개발 방법.
전통적인 TDD 개발론의 흐름:
1. Unit 을 위한 Test set 을 정의.
2. 해당 Unit 을 구현.
3. 구현이 Test 를 통과하는지 검증.
이 흐름에서는 Test 의 관점에서 각 Unit 에게 기대하는 행위가 명시되어 있지 않다.
BDD
이런 문제점을 안고 BDD 는 각 Unit 에게 기대되는 행위들을 명시적으로 밝히면서 출발한다.
BDD의 아버지 Dan north 는 명시화에 대해 한 가지 Template 을 만들어 채택한다.
1. 어떤 값이 주어질 때 (Given)
2. 이런 이벤트가 발생한다면 (When)
3. 그 결과는 이러해야 한다. (Then)
그는 Test 라는 개념보다 "Behaviour" 라고 말했을 때
Test unit 의 의도가 좀 더 분명해진다고 생각했고,
Test method 이름에 "should" 를 넣기 시작했다.
should 라고 Test method 를 작성함으로써
Test unit 에 기대되는 행위가 분명해지기 때문이다.
BDD 에서는 Test unit 의 의도가 분명히 드러나는 것이 중요하다는 것을 알았다.
그런데, 조금은 모호하다. TDD 역시 BDD 의 방식으로 작성할 수 있지 않나?
(이전의 TDD 포스팅에서도 Unit test 내부의 구현이 모두 given,when,then 의
흐름을 따르고 있다.)
Dan north 는 다음과 같이 말한다.
"BDD는 TDD 사용자들의 공식화된 좋은 습관을 기반해 형성됐다.
하지만, 개발자의 언어로 작성되는 TDD에 반해 BDD 는 테스트 시나리오를 읽을 대상이 더 넓혀진 개념이다."
따라서, BDD 는
요구사항이 분명한 예제를 채택해 행위를 표현하는 시나리오로 작성하고,
유비쿼터스 랭귀지 즉, 개발자 뿐만 아니라 사용자와 분석가, 테스터까지도
이해할 수 있는 언어로 시나리오를 작성한다.
결국, BDD 는
누구나 알아볼 수 있는 언어로 기대되는 행위를 명세화한 시나리오를 기술함으로써
프로젝트 내에 개발 뿐만 아니라 다른 업무를 가진 구성원들 간에도 의사소통을 원할하게 한다.
BDD 프레임워크
BDD 프레임워크 사용 시 TDD 와 코드 상의 가장 큰 차이점은 story 파일이다.
story 파일은 비 개발자와 소통을 돕고 앱의 행동을 규정해준다.
BDD 프레임워크들은 story 작성을 기술적으로 지원해준다.
story 파일은 크게 User story 와 Scenario 로 구성된다고 할 수 있다.
User story 는 이 프로젝트에서 무엇이 개발되어야 하는지에 관한 내용이고,
Scenario 는 그에 따른 구체적인 예시이다.
User story
User story 는 보통 다음의 형태를 가진다.
As a <Stakeholder>
I want <Capability>
So that <Value>
예를 들어,
날씨 정보에 대한 앱을 제작한다면 User story 는
여행자로서 나는
도시의 날씨 확인할 수 있고
따라서, 여행지의 날씨를 미리 알 수 있다.
정도가 될 수 있다.
이런 형태를 통해 "누가", "무엇을", "왜" 에 대한 대답을 명확히 할 수 있다 .
Scenario
다음과 같은 형태를 가진다.
Given <Precondition>
When <Action>
Then <Output>
하나의 User story 에 여러개의 Scenario 를 가질 수 있다.
User story 와 Scenario 작성에는 기술적 용어를 피해 누구나 이해할 수 있게 해야 한다.
Scenario 가 작성되면 이를 구현하기 위한 Test 작성을 시작한다.
정리하며
BDD 에 대한 개념을 알아보았다. TDD 와 BDD 를 어떤 동떨어진 개발 방법처럼 생각하기보다, BDD 가 TDD 를 근간으로 어떤 지향점을 부각시킨 개념인지 생각하면 좋을 것 같다.
TDD나 BDD 는 단순히 개념을 숙지하고 바로 적용할 수 있는 것은 아니다. 여전히 많은 회사들이 이런 개발 방식의 도입을 망설이고 있다고 하는데, 이는 이러한 기술들이 많은 경우에 실제로 해봐야 득인지 실인지 아는 경우가 많고, 개발자 개개인의 안목만으로 모든 구현체 개발에 반드시 적용해야 한다고 하는 것 또한 무리가 있기 때문이다.
'개발 관련 이것저것 > 개발 방법론' 카테고리의 다른 글
| TDD 관련 포스팅 정리 - 모든걸 다 Test-Drive 해야할까? (The Pragmatics of TDD, Test Trivial Code, What to Test and Not to) (0) | 2021.09.16 |
|---|