테스트 주도 개발(Test-Driven Development)은 때로 테스트 우선 개발이나 테스트 주도 설계라고도 불리는데, 구현 코드를 한 줄도 작성하기 전에 단위 테스트를 먼저 작성하는 방법이에요.
Exercism에서는 테스트가 곧 요구 사항이에요!
여러분이 푸는 모든 연습 문제(새로운 개념을 가르치지 않는 문제들이에요)에는 무엇을 해야 하는지 큰 틀에서 설명하는 지시문이 함께 있어요.
이 지시문은 Exercism의 70개가 넘는 언어 트랙이 모두 함께 사용하기 때문에, 특정 프로그래밍 언어에만 해당하는 구현 세부 사항은 의도적으로 다루지 않아요.
일부 언어 트랙은 더 구체적인 설명을 덧붙여 주기도 하지만, 모든 트랙이 그런 것은 아니에요.
연습 문제를 풀기 시작할 때는 지시문을 꼼꼼히 읽어 봐요.
지시문은 풀이를 어떻게 구현해 나가면 되는지 큰 그림을 그려 줘요.
하지만 전체적이고 정확한 요구 사항을 알려면 _테스트_를 읽어야 해요.
- 결과가 특정한 종류의 자료 구조여야 하나요?
- 결과가 어떤 순서로 정렬되어야 하나요?
- 예외는 어떻게 처리해야 할까요? 등등.
주어진 테스트가 모두 실행되고 통과하면 문제를 푼 거예요.
다시 말해, 풀이는 지시문을 "맞아 보이게" 해석한 것이 아니라, 주어진 테스트를 만족하는 프로그램이에요.
테스트가 바로 그 문제의 완전한 요구 사항이에요.
Exercism은 TDD를 어떻게 적용할까요?
Exercism은 여러분을 위해 단위 테스트 모음을 이미 작성해 두었어요.
여러분의 목표는 그 단위 테스트가 모두 통과할 만큼만 코드를 담은 풀이를 작성하는 거예요.
이 점을 기억해 두세요. TDD 방식은 풀이에 도달하도록 도와주지만, 거기서 멈출 필요는 없어요.
요구 사항을 넘어서 풀이를 확장하고 싶다면 얼마든지 그래도 돼요.
멘토와 함께 작업하기로 했다면(테스트가 통과되기 시작하면 꼭 한번 해보길 권해요), 멘토는 처음 작성한 구현을 리팩터링하고 다듬도록 도와주거나 새로운 단위 테스트를 제안해 줄 수도 있어요.
온라인 에디터에서 작업하기
Exercism 웹사이트의 코드 에디터에서 작업할 때는 테스트를 읽을 수는 있지만 수정할 수는 없어요.
테스트 파일에 적힌 "skip" 방식과 상관없이, 테스트를 실행할 때마다 모든 테스트가 실행돼요.
실패한 테스트가 여러 개일 때, 웹사이트는 처음에 첫 번째 실패 결과만 보여줘요.
다른 실패 항목을 클릭해서 펼쳐 볼 수도 있어요!
첫 번째 결과가 항상 가장 유용한 정보라는 보장은 없어요.
실패한 테스트가 많다고 낙담하지 마세요.
하나씩 통과시키는 데 집중해요.
로컬에서 작업하기
많은 트랙이 테스트 파일에서 "건너뛴" 테스트를 사용해요.
처음에는 첫 번째 테스트만 "활성" 상태이고 나머지는 비활성 상태예요(어떻게 처리되는지는 트랙마다 달라요).
여러분의 환경에서 테스트 모음을 실행하면 첫 번째 테스트만 실행돼요.
이렇게 하는 이유는 다음 작업 흐름을 따르도록 장려하기 위해서예요.
- 새 코드를 추가하기 전에 테스트 모음을 실행해요. 실패하는 테스트가 보일 거예요.
- 테스트를 통과할 만큼만 딱 충분한 코드를 추가해요.
- 테스트 모음을 실행해요.
- 테스트가 여전히 실패하면 2단계를 반복해요.
- 테스트가 통과하면 원하는 대로 코드를 리팩터링해요. 이때 활성 상태인 테스트가 모두 통과하는지 확인해요.
리팩터링에는 이런 것들이 포함될 수 있어요:
- 중복된 코드 제거,
- 긴 함수를 더 작은 함수로 나누기,
- 주석 추가 등.
- 다음 테스트의 "건너뛰기"를 해제하고 1단계부터 반복해요.
모든 테스트의 건너뛰기를 해제할 때까지 이 단계를 반복해요.
모든 테스트가 통과하면, 축하해요, 문제를 해결한 거예요!
테스트의 건너뛰기를 해제하는(또는 활성화하는) 정확한 방법은 트랙마다 달라요.
어떤 트랙에서는 주석 처리나 어노테이션 제거일 수 있고, 어떤 트랙에서는 속성을 true에서 false로 바꾸는 것일 수도 있어요.
시간을 내서 해당 트랙의 문서를 읽어 봐요. 자세한 내용이 설명되어 있어요.
테스트를 건너뛰지 않는 트랙이라면, 이 작업 흐름을 적용하는 방법은 테스트를 주석 처리하고 하나씩 주석을 해제하는 것만큼 간단할 수도 있어요.
테스트 주도 개발을 하는 이유
"수레를 말 앞에 놓는 격"처럼 보일 수도 있지만, 구현 코드를 작성하기 전에 단위 테스트를 작성해야 할 좋은 이유가 여러 가지 있어요.
-
설계.
먼저 코드를 어떻게 구현할지로 바로 뛰어드는 대신, 프로그램의 인터페이스(기능을 세상에 어떻게 드러내는지)를 먼저 생각하게 해줘요.
잘 설계된(그리고 테스트 가능한!) 인터페이스를 갖는 것이 효율적인 구현을 갖는 것보다 더 중요할 때가 많아요.
-
규율.
테스트 작성은 흔히 귀찮은 일이나 나중에 할 일로 여겨져요. 하지만 테스트를 먼저 작성하면, 결국 대부분 또는 모든 코드 기능을 다루는 단위 테스트를 충분히 작성하게 돼요(어쩌면 끝내 시작조차 못 할 수도 있는 것과는 달라요).
-
일이 줄어요.
테스트 하나를 쓰고, 그 테스트를 통과할 코드를 쓰고, 다시 다음 테스트를 쓰는 촘촘한 주기를 반복하면, 코드가 자연스럽게 자라나요.
그러면 흔히(항상 그런 것은 아니지만) 헛수고가 줄어들어요. 필요한 코드는 모두 쓰고, 필요 없는 코드는 하나도 쓰지 않게 돼요.
더 읽어보기
