Mission # 1 계산기 (온보딩 미션) 후 회고

이현정·2022년 7월 6일

NEXTSTEP 넥스트스텝 자스 계산기

NEXTSTEP: TDD with JavaScript

목록 보기

2/6

1차 온보딩 미션(6/28~7/5) 계산기 만들기가 끝났다.
온보딩 미션을 진행하며 배운 점들을 정리하고 넘어가고자 한다.

핵심 개념

TDD란 (부제: TDD vs BDD)

What, TDD란 무엇인가

어제는 프로젝트에 시작하기에 앞서 TDD가 일단 무엇인지부터 정확히 개념을 짚고 가자고 했다.

일단 이해한 정도로만 적는다면, TDD 란 Test Driven Development 의 약자로, 즉, 테스트가 개발을 끌어나가는 방식이다. 기존의 코드를 짜고 테스트를 하는 일반적인 방법이 아니라 "테스트를 먼저 짜고" 그에 맞춰 코드를 짜는 것이다. 테스트를 할 수 있는 코드를 짜고, 이게 실패하면 왜 실패했는지 수정하며 코드를 고쳐나가는 식이다.

이런 방식을 흔히 red & green 이라고 한다. red: 빨간불. 테스트가 실패하면 일단 멈춰서 테스트를 패스하기 위한 최소한의 코드를 짜는 과정 -> green: 초록불. 테스트가 통과되면 기능을 개선하기 위해 또다른 테스트 코드를 짬. 이런 과정의 반복이란 뜻.

비교군으로 BDD(Behavior Driven Development)가 자주 언급되는데 아래에서 설명하겠다.

Why, 왜 TDD 를 사용해야 하나: 애자일(Agile)

TDD 개념의 창시자 켄트 백은 애초에 애자일 선언문의 17명의 오리지널 서명인 중 한 명이었다고 한다. 그만큼 TDD 는 애자일 방법론과 관계가 깊다. 아니, 사실 왜 TDD냐? 라는 질문에 1차 강의에서 많은 사람들이 '애자일(Agile)'을 언급했다. 그렇다면 애자일이 무엇인지 먼저 짚고 넘어가자.

애자일(agile): 기민한, 좋은 것을 빠르고 낭비없게 만드는 것

애자일 방법론은 문서를 통한 개발이 아니라, 실질적인 코딩을 통한 방법론이라고 할 수 있다.

계획을 통해서 주도해 나갔던 과거의 방법론
이와 다르게 앞을 예측하며 개발하지 않고
일정 주기를 가지고 끊임없이 프로토 타입을 생성
추가, 제거되는 요구 사항에 대해 능동적으로 대처하고 수정

이런 단계를 반복하여 하나의 커다란 소프트웨어를 개발에 나가는 adaptive style

TDD는 이러한 애자일 방식을 가능하게 해준다. 최소한의 단위의 테스트를 추가 & 수정 하는 방식으로.

BDD === 잘 짠 TDD

BDD(Behavior Driven Development)은 행동 주도 개발이다. BDD는 사실 TDD에서 파생된 개발 방법론으로, 개발자와 비개발자의 협업 과정을 녹여낸 방법이다.

조금 더 정리해보자면,

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

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

(좌)TDD에서 발생가능한 문제를 / (우) BDD에서는 해결 가능하다