TDD, BDD란?

TDD (Test Driven Development)

TDD란, 말 그대로 테스트 주도로 개발을 이끌어 나가는 것이다.

즉, 테스트를 먼저 작성하고 나서, 테스트가 정상적으로 돌아갈 때 까지 테스트를 하면서 코드를 작성하는 작업이라고 볼 수 있다. 원하는 작업이 제대로 돌아갈 때까지 테스트와 코드 작성을 무한대로 반복하며 개발을 하면 된다. 

 

테스트의 종류는 되게 다양한데, 

• 단위(Unit) 테스트
• 통합(Integation) 테스트
• E2E(End to End) 테스트
• 회귀(Regression) 테스트
• 성능(Performance) 테스트

모든 테스트를 다 진행하면서 개발하기는 쉽지 않기 때문에 이 중에서도 우리는 E2E 테스트를 먼저 다뤄봤다. End to End 테스트는 Endpoint 간의 테스트라고도 하는데, 사용자의 입장에서 사용자에게 직접 노출되는 부분을 점검한다. 

 

페어프로그래밍을 하며 TDD라는 개념을 처음으로 들었을 때, 사실

아 그냥 Test를 작성하라는 거구나?
-> 그런데 테스트를 작성할 코드가 없는데? 
-> 그럼 코드를 먼저 작성해야겠다!
-> 코드작성 

이렇게 진행이 되었었는데, 이건 결국 TDD가 아니라는 것을 다 만들고 나서야 깨달았다^^;

테스트를 만들기만 하면 TDD가 자동으로 되는 줄 알았다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

TDD에 대한 수업을 듣고 나서야 우리는 코드주도개발(?)을 했다는 것을 알게 되었다. 

 

TDD에 대한 개념을 조금이나마 이해한 후에, 든 생각은 "어? 그런데 왜 TDD를 하지? 그냥 우리가 손으로 하던 테스트랑 똑같은거 아닌가?" 였다. 그런데 직접 테스트를 돌려보니 엄청나게 생산성이 빨라진다는 것을 깨달았다. 역시 기계 짱. 그리고 하나 하나 생각하며 테스트하지 않아도 한번 테스트 코드에 입력해두면 다 - 해주니까 정말 와방 굿이었다. 

TDD의 장점 

테스트가 가능한 코드를 만든다는 것은 결국, 테스트하기 쉽게 만들어진 코드를 만드려고 노력한다는 것이라고 할 수 있다. 이렇게 개발하다보면, 각 모듈의 역할이 단순해지고 명확해진다. 즉 모듈의 크기를 줄일 수 있게 되고 모듈과 계층 간의 커플링을 적게 만들어 결국 프로젝트의 유지보수와 확장을 더 쉽게 한다. 그렇기 때문에, 아래와 같은 장점이 있다.

 

• 각 모듈의 역할이 단순해지고 명확해짐
• 프로젝트의 유지보수와 확장이 쉬움
• 수동 테스트에서 시간을 단축할 수 있음
• 놓칠 수 있는 것들을 반복 테스트하기 좋음
• 프로젝트의 품질을 높이고, 효율적인 테스트 경험과 사용자의 입장을 고려한 개발을 진행할 수 있도록 해줌
• 실제 사용자의 실행 환경과 거의 동일한 환경에서  테스트를 진행하기 때문에, 실제 상황에서 발생할 수 있는 에러를 사전에 발견할 수 있음

아직 테스트 주도 개발에 대해 공부중이기 때문에.. 이론뿐이긴 하지만.. 그래도 더 많은 프로젝트를 통해 곧 체득하게 되리라 믿으며.. 허헛 ㅎㅎ 

 

내가 직접 코드를 구현하며 알게된 장점들을 정리해 보자면, 

1. 내가 구현한 기능을 자동으로 테스트해주기 때문에, 기능을 만들며 귀찮게 하나하나 입력하지 않아도 좋다.
2. 테스트를 먼저 작성하다보니 기능을 만들기 전에 내가 만들어야 하는 기능들에 대해 조금 더 명확하게 그릴 수 있다.

요정도 였다!

 

확실히 Calculator 미션을 진행할 때와 Racing Car 미션을 진행할 때에 큰 차이가 있었다고 생각한다.

Calculator 미션을 진행할 때에는 처음에 코드를 다 구현하고 나서 테스트 코드를 짰었는데, 테스트를 돌려서 에러가 나서 고치면 다른 곳에서 에러가 나는 상황이 반복되었다면, Racing Car 미션에서는 그런 에러들을 많이 줄일 수 있었다. 확실히 함수들이 짧아지고 기능들이 명확해져서 그런 것 같다는 생각을 했다. Calculator는 거의 일주일을 잡고 있었던 것 같은데, Racing Car는 3일정도 걸렸던 것 같다. ㅎㅎ

 

BDD (Behavior Driven Development) === 잘 짠 TDD

BDD는 말 그대로 행동 주도 개발이다. 사용자의 행위까지 생각하고 테스트하며 개발한다. BDD는 TDD의 한 종류로, 프론트엔드에서 조금 더 장점이 두드러지는 경향이 있다. 메소드 위주의 TDD보다 행동을 조금 더 강조하기 때문이다. 

 

조금 더 정리해보자면, 

TDD를 하면서 개발을 하다보면 Testcase에 대해서도 계속 유지보수해야하는데 귀찮기도 하고, 마감기한이 정해진 프로젝트라면 일정에 대해 압박을 받을 수도 있다. 그렇기 때문에 매번 개발을 진행하면서 기능에 대해 예외사항에 대해 매번 생각하고 Testcase를 작성하는 것은 생각보다 비용이 많이 들어가는 일이라고 볼 수 있다. 

하지만 만약 여기에서 이미 작성된 요구사항이나 기획서가 있고, 그에 맞추어 테스트 케이스를 작성하게 된다면, 위와 같은 시간에 대한 비용이 줄게된다. 바로 이게 BDD이다.

 

즉, BDD는 TDD에서 파생된 개발 방법론으로, 개발자와 비개발자의 협업 과정을 녹여낸 방법이다. 

(좌) TDD에서 발생할 수 있는 문제 / (우) (좌)에서 발생 가능한 문제를 BDD에서는 미리 잡아낼 수 있다.

 

이렇게 보면 BDD든, TDD든 하나만 선택해야하는 거 아니야? 라고 생각이 들 수 있지만(바로 나), 두개는 상호 배타적인 관계가 아니라 상호 보완적인 관계이다. 프로젝트에서 BDD의 테스트케이스로 시나리오 검증을 하고, 해당 시나리오에서 사용하는 각 모듈들은 TDD의 테스트케이스로 검증을 하는 방법이 좋다. 아래 그림을 보면 더 이해하기 쉽다.

 

아래는 TDD와 BDD를 비교한 표이다. 각자의 장점이 뚜렷하니, 자신의 프로젝트에 맞게 선택해 테스트 코드를 작성하면 될 것 같다.

 

 

그래서 위와 같은 내용을 배운 것을 바탕으로

계산기 기능을 진행할 때에, 아래와 같이 어떤 Flow로 사용자가 계산기를 이용하게 되는지 생각을 먼저 해보고, 테스트 코드를 짤 수 있었다. 아래는 계산기의 + 기능을 구현할 때의 BDD 예시다.

Given 
  - 사용자가 처음에 페이지에 접속하고 나면, display 값이 0이다. 
When 
  - 유저는 2를 클릭하고, 디스플레이에 2가 보여진다. 
  - 유저는 +를 클릭한다. 
  - 유저는 4를 클릭하고, 디스플레이에 4가 보여진다. 
  - 유저는 =를 클릭한다. 
Then 
  - 디스플레이 값은 6이 된다.
  
  

 

수업을 들으며 TDD와 BDD에 대해 알게 되고, 크루들이 알려준 아래의 발표 영상으로 TDD와 BDD에 대해 조금 더 가닥을 잡을 수 있었던 것 같다! 너무 유용한 영상이었다. ㅎㅎ 

tv.kakao.com/channel/3693125/cliplink/414004682

카카오 if - "Kotest가 있다면 TDD 묻고 BDD로 가!"