테스트 주도 개발 TDD / BDD, 그리고 애자일

테스트 주도 개발 TDD / BDD

 

 

이번 여름 방학동안 기존 개발했던 흐릿 프로젝트를 함께 했던 팀원분과 리팩터링하는 시간을 갖기로 하였다.

 

그리고 주어진 시간에 쫓겨 테스트 코드를 작성하지 못하였던 것이 후회되어

 

TDD 방법론을 적용하여 다시 디벨롭 해보려고 하였기에 테스트 방법론에 대하여 공부하고 기록하게 되었다.

 

---

애자일 방법론?

 

테스트 방법론을 공부하며 들어는 봤지만 정확히 뭘 뜻하는 지는 몰랐던 에자일 방법론에 대해서 공부했다.

 

---

애자일 소프트웨어 개발 선언

 

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고있다.

이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

 

=  공정과 도구보다 개인과 상호작용을  =

=  포괄적인 문서보다 작동하는 소프트웨어를  =

=  계약 협상보다 고객과의 협력을  =

=  계획을 따르기보다 변화에 대응하기를  =

 

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

© 2001, 상기 저자들
이 선언문은 어떤 형태로든 자유로이 복사할 수 있지만,
본 고지와 함께 전문으로서만 가능하다.

 

---

 

위는 번역된 애자일 선언문이며 애자일 방법론이 추구하는 바를 알 수 있다.

 

정해진 계획과 문서에 의존하여 a,b,c,d 순으로 개발을 진행해나가는 것이 아니라

 

미래를 예측하기 보다는 주기적으로 제작 프로토타입을 시험해보는 철저한 관리를 통한 개발 방법론이라 할 수 있으며 끊임없이 개발하고 수정하는 일을 반복하면서 고객이 가장 만족할 수 있는 방향으로 소프트웨어를 개발한다.

요약하면 컴퓨팅 환경과 시대가 변화함에 따라 계획 중심적이며 유연함이 없는 기존 폭포수 모형 개발론 방식(Waterfall Model) 방식은 한계점이 명확히 드러났고, 한계를 극복하기 위해 개발과 함께 즉시 피드백을 받아 유동적으로 개발하도록 만들어진 방법론이 바로 애자일 방법론이다.

 

 

https://www.notion.so/pgmjun/53e0b0da38cc4383a0a9ff1d8899439a

(폭포수 모형 개발론이란)

 

 

구체적으로 애자일 방법론에는 칸반, TDD, BDD 등 다양한 방법이 존재하는데 오늘은 TDD, BDD에 대해서 알아보자.

 

---

 

TDD (Test-driven development)

 

TDD는 말 그대로 테스트 주도 개발을 의미한다.

 

테스트가 이끌어나가는 개발 환경을 표현할때 사용되며

 

쉽게 말해 실제 구현 코드를 작성하기 전에 테스트 코드부터 작성하는 방식이라는 것이다.

 

 

"선 테스트, 후 구현"

 

이것이 TDD가 뜻하는 바이다.

 

 

TDD 방법론의 개발방식

 

1. 요구사항을 검증하는 테스트 케이스 작성

- 이때 테스트가 실패하더라도 알아볼 수 있고 컴파일만 가능하게 테스트 코드를 작성하면 된다.

 

2. 테스트 케이스 통과하기 위한 최소한의 코드 생성

 

3. 최종적으로 작성한 코드를 기준으로 표준에 맞게 리팩토링

 

 

장점

- 코드의 확장성 및 유지보수 용이 (코드의 모듈화가 자연스럽게 이루어짐)

- 프로그램 소스코드 기록 (테스트 코드로 인해서 코드의 목적성과 과정을 기록하는 효과)

- 총소유비용(TCO) 절감

 

단점

- 숙련되기까지 다소 시간이 소요된다.

- 선행 투자가 많이 필요하다.

 

 

 

 

 

 

---

 

BDD (Behavior-driven development)

 

BDD는 행위 주도 개발로 해석할 수 있다.

 

기본적으로 TDD에 기반을 두고 있으며 큰 차이가 나지 않는 것 처럼 보일 수 있지만, BDD는 TDD에서 한 발 더 나아가 테스트 케이스자체가 요구 사양이 되도록 개발하는 방식이다.

 

TDD는 테스트 단위가 함수 단위로 매우 작아서 작성하는 대부분의 함수가 테스트 대상에 포함되기 때문에 현업에서 사용하기에는 다소 번거로움이 느껴질 수도 있다.

 

그래서 TDD에서 파생되어 등장한 BDD는 함수 단위의 테스트를 권장하지 않고 시나리오 기반의 테스트 케이스를 작성한다.

 

이때 이 시나리오는 개발자가 아닌 사람이 봐도 이해할 수 있을 정도여야 한다.

(자연어같아야 한다)

 

 

시나리오는

Given, When, Then 구조를 가지는 것을 기본 패턴으로 권장한다.

 

 

 

장점

- 비지니스에서 요구하는 가치를 제공

- 다른 커뮤니티 구성원들도 참여할 수 있다.

(프로그래머뿐만 아니라 전 구성원이 이해와 협의할 수 있다는 점에서 TDD 보다 좀 더 애자일스러움)

 

단점

- BDD를 지원하는 소프트웨어 툴은 비교적 적다.

 

 

 

---

 

TDD와 BDD 의 차이

 

TDD는 개발코드의 완성이 목적

BDD는 개발 결과의 검증이 목적

 

조그마한 개발팀에 있고 일하는 대상이 모두 개발자라면 굳이 BDD를 사용할 필요가 없다.

 

TDD는 코드 자체에 집중한 테스크 코드 작성을 중시하고

BDD는 프로그래머가 아닌 구성원들도 함께 검증하고 소통하여 의견을 반영해나가는 방식이기 때문이다.

 

 

 

 

---

 

테스트 코드를 작성하는 이유

 

- 일일히 코드를 실행해보며 확인하지 않아도 기능이 정상적으로 작동하는지 확인할 수 있다.

 

- 결함이 있다면 사전에 발견할 수 있다.

 

- Refactoring시에 기존 소스와 같은 결과를 출력하도록 동작하는지 확인이 가능하여 제대로 refectoring 하였는지 알 수 있다.

 

- 코드 작성자의 의도, 사용법 등이 드러나 프로젝트에 대한 문서로서 작용할 수 있다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

reference

https://blog.metafor.kr/159

http://www.incodom.kr/%ED%8F%AD%ED%8F%AC%EC%88%98_%EB%B0%A9%EB%B2%95%EB%A1%A0#h_e4f946f397a0775cf92efb8588c73f64

https://m.blog.naver.com/sundooedu/221193074730