🛠️

TDD & BDD

테스트를 알아야 하는 이유

TDD라는 말을 들어봐서 적용해보고 싶다면? 클린코드가 무엇인지 기준을 잡아보고 싶다면? 리팩터링은 언제, 어떻게 하면 좋을지 알고 싶다면?

이 문서를 보고 나면

TDD로 간단한 counter 기능을 구현할 수 있다.

클린코드로 나아가기 위한 리팩터링 기준점을 스스로 만들어 나갈 수 있다.

1. TDD(Test Driven Development)

TDD는 테스트를 먼저 작성하고 그 후 실제 코드를 작성하는 방법입니다. TDD는 켄트 백(Kent Beck) 이 개발 혹은 널리 알린 개념입니다. 흔히들 개발전에 테스트 코드를 짜는게 TDD라고만 생각할 수 있는데, 그보다 본질적인 의미는 문제를 정의하고, 그 해답을 찾아가는 과정이라는게 TDD의 기본 취지입니다. 그리고 테스트도구는 그 철학을 이행하는 도구입니다. TDD는 주로 개발 코드를 유닛으로 구현합니다. 코드의 기능을 검증하는게 중요한 목표

장점

테스트를 먼저 작성하기 때문에 전체 코드에서 얼마나 많은 코드가 테스트되는가를 측정하는 테스트 커버리지 비율이 자연스럽게 높아진다.

테스트 되는 것만 코드로 작성하므로 코드가 방대해지지 않는다.

버그때문에 발생하는 시간 낭비 줄여주고, 코드가 원하는 바를 명확히 달성하는지 쉽게 확인

방법

테스트를 먼저 작성한다. 만족하는 코드가 없는 상태이므로 테스트는 실패함

테스트를 통과하는 코드를 작성한다.

리팩터링: 중복이 보이거나 더 개선할 방법이 있다면 코드를 개선한다.

3대 원칙 - 로버트 C. 마틴 (밥 아저씨, 클린 코더)

실패할 테스트를 작성하기 전에는 아무런 프로덕션 코드도 작성하지 않는다.

실패할 테스트 말고는 작성하지 않는다.

현재 실패한 테스트를 만족시키는 코드 외에는 작성하지 않는다.

좋은 테스트의 조건

•

실행 속도가 빨라야 함.

•

내부 구현(테스트하지 않는 부분)을 변경했다고 해서 테스트가 실패하면 안된다. 인터페이스(입출력 위주)를 중심으로 작성.

•

버그를 찾을 수 있어야 한다. 만들었다고 끝이 아님 테스트 시나리오를 잘 설정해야 함.

•

테스트 결과에 일관성이 있어야 한다. 코드가 변하지 않았다면 테스트 결과는 항상 동일 해야 한다.

•

의도가 명확히 드러나야 한다.

2. BDD(Behaviour Driven Development)

BDD에서는 테스트 케이스 자체가 요구사양이 되도록 개발합니다. 그래서 유저 스토리를 먼저 작성해야 하는데요. TDD에 대한 코칭을 하던 BDD의 아버지 댄 노스(Dan north)는 TDD에서 다음과 같은 벽에 마주쳤었습니다.

프로세스의 어디서부터 시작해야 하는가(Where to start in the process).

무엇을 테스트하고 또 무엇을 하지 말아야 하는가(What to test and what not to test).

한 번에 얼마만큼 테스트해야 하는가(How much to test in on go).

테스트를 어떻게 명명해야 하는가(What to call the tests).

테스트가 실패하는 이유에 대해 어떻게 이해해야 하는가(How to understand why a test fails).

이에 댄 노스와 그의 동료들은 하나의 템플릿을 만들어 채택했는데 아래와 같았습니다.

특정 값이 주어지고(Given)

어떤 이벤트가 발생했을 때(When)

그에 대한 결과를 보장해야 한다(Then).

댄 노스는 TDD 코칭을 하던 시절 ‘Test’라는 단어를 사용하지 않는 편이 사람들이 좀더 TDD의 원리를 이해하는 데 도움될 것이라 생각했고, Test라는 개념보다는 ‘Behaviour’라는 개념을 썼을 때 테스트 유닛의 의도가 좀더 명확해진다는 것을 깨달았다고 합니다. 그리고는 모든 테스트 메소드명에 ‘should’를 넣기 시작했습니다.

should는 영문법에서 어떤 행위를 기대한다는 조동사입니다. 이를 사용함으로써 개발자는 더 이상 테스트 메소드를 작성할 때 어떻게 명명해야 하는지 혼란을 느끼지 않아도 되고, 이로써 테스트 유닛에 기대되는 행위들이 명확해졌습니다. 또한 작성하는 코드가 기대하는 행위에 맞지 않는다면 이는 리팩토링의 징조가 되기 때문에 리팩토링을 통해 모든 구현 코드의 의도 또한 명확해집니다.

앞서 진행한 계산기 미션을 예로 들어보겠습니다.

스토리

Given (주어진 환경)

•

유저에게 계산기 화면이 렌더링 된 후

When (행위)

•

유저가 숫자 4을 클릭한다.

•

유저가 + 버튼을 클릭한다

•

유저가 2를 클릭한다.

•

유저가 = 을 클릭한다.

Then (기대결과)

•

계산기 화면에는 6이라는 숫자가 보여진다.

이런 유저의 행위를 그대로 테스트코드를 이용하여 재현합니다. 이처럼 BDD는 행위를 중점으로 기술하면서 테스트를 하는건데, 사실상 TDD와 사이클은 비슷합니다. 그래서 혹자는 BDD를 잘된 TDD라고 표현하는데요. 결국 중요한건 문제를 정의하고, 그 해답을 찾아가는 과정 이라는겁니다.