테스트 주도 개발 / 켄트 백

블로깅의 배경

지금 소개할 책은 이번 주까지 진행되는 우테코 레벨 1 단계의 첫 번째 미션인 자동차 경주 미션을 진행하며 알게 된 TDD(Test-Driven Development)에 관한 책이다. 이번 미션을 진행하며 처음 테스트 코드를 짜 봤고, 이번 미션의 학습목표인 TDD에 대해 더 알고자 책을 읽어보게 됐다. 원래는 블로그에 글을 쓰지 않고, 연휴 기간 동안에 읽어야 지하는 생각을 갖고 있었으나 '아 내가 이거 연휴 동안 읽으려나...' 하는 내 의지력을 스스로 의심하게 됐다. 그러다 로키와 이야기하며 로키가 진행 중인 to-do list 캠페인(?)에 참여해 읽을 수밖에 없는 환경에 나를 두기로 했다. 

---

이 책은 총 3부의 큰 줄기로 구성돼 있다. 1부에서는 서로 다른 두 가지 화폐를 이용할 수 있는 일종의 계산기를 만드는 예제를 글로 자세하게 설명하며 따라올 수 있게 한다. 책을 읽을 때 실제로 코드를 먼저 이해하고, 직접 코드를 구현해보며 읽었다. 그리고 2부에서는 파이썬을 이용해 자신만의 테스팅 프레임워크를 만들 수 있는 방법에 대한 설명과 3부에서는 TDD의 인기 있는 패턴 모음에 대한 소개와 설명이 있다. 2부는 파이썬에 관한 내용이기 때문에 패스, 3부는 아직 TDD에 익숙하지 않다는 합리적인 이유(핑계)로 읽지 않고 책에 대한 감상만을 전한다.

실제 1부의 거의 모든 내용은 예제로 이뤄져 있기 때문에 직접 책을 활용해 저자와 페어프로그래밍 한다 생각하고 예제들을 따라가 보는 것을 추천한다.

---

나 == TDD, 그러나 TDD는 좋아해야 한다.

테스트 주도 개발이란?

책에서는 테스트 주도 개발에 대해 프로그래밍을 하며 느끼는 두려움을 줄이고, 잠재력을 끌어내는 방법론으로 소개한다. 여기서의 두려움이란 새로운 프로젝트를 진행하거나 이전의 프로젝트를 수정해야 할 일이 생길 때 이전에 작성한 코드를 보며 생기는 두려움을 말한다. (내가 프리코스, 미션을 시작할 때 느꼈던 두려움과 같다.) 이런 두려움은 우릴 망설이게 하고, 커뮤니케이션을 덜 하게 만들며, 피드백받는 것을 피하게 하고, 결국 두려움은 프로그래밍에 어떤 도움도 되지 않는다. 저자는 TDD를 통해 이런 두려움을 줄일 수 있다고 말한다.

 

 

 

테스트 주도 개발의 목표

테스트 주도 개발의 방법을 얘기하기에 앞서 테스트 주도 개발의 궁극적인 목표는 '작동하는 깔끔한 코드'이다. 목표를 이루기 위해 저자는  테스트 주도 개발 방식을 따를 것을 말하며 테스트 주도 개발의 방법은 1. 작동하는 코드를 작성하고, 2. 깔끔하게 만드는 과정의 흐름으로 이뤄져 있다.

 

 

 

테스트 주도 개발의 순서

1. 빨강 - 실패하는 작은 테스트 만들기. 컴파일조차 실패한다.

2. 초록 - 어떤 방법을 사용해서라도 테스트가 통과될 수 있는 코드를 만든다. (책에서는 이 방법을 죄악이라고 표현했다.)

3. 리팩토링 - 2번에서 일어난 과정에서 발생하는 모든 중복을 제거한다.

 

1, 2는 테스트 주도 개발의 목표 중 작동하는 코드를 만드는 과정. 3은 깔끔한 코드를 얻는 과정으로 볼 수 있다. 이 TDD 과정을 통해 두려움을 줄일 수 있는 용기를 가질 수 있다고 한다. 

 

 

아래는 TDD 과정의 리듬이다. 위의 순서를 좀 더 자세히 표현했다고 생각하면 될 것 같다. 테스트 주도 개발의 리듬과 3부에 소개된 테스트 주도 개발 패턴을 정리하며 글을 마친다.

 

 

테스트 주도 개발의 리듬

1. 테스트 하나를 추가한다.
2. 모든 테스트를 실행하고 새로 추가한 것이 실패하는지 확인한다.
3. 코드를 조금 바꾼다.
4. 모든 테스트를 실행하고 전부 성공하는지 확인한다.
5. 리팩토링을 통해 중복을 제거한다.

 

 

테스트 주도 개발 패턴

격리된 테스트

테스트를 실행하는 것이 서로 어떤 식으로 영향을 미쳐야 좋은가?
아무 영향이 없어야 한다.

 

저자는 자신의 경험을 통해 테스트는 전체 애플리케이션을 대상으로 하는 것보다 좀 더 작은 스케일로 하는 게 좋으며 각각의 테스트는 다른 테스트와 완전히 독립적이어야 한다고 강조한다. 독립적인 테스트를 통해 실행 순서에 독립적인 테스트를 만들 수 있으며, 응집도는 높고 결합도는 낮은 객체의 모음을 구성할 수 있다고 말한다. 

 

 

테스트 목록

뭘 테스트 해야 하나?
시작하기 전에 작성해야 할 테스트 목록을 모두 적어두자.

 

프로그래밍 스트레스를 줄이기 위해 발 디딜 곳이 확실하기 전엔 결코 발을 떼어 전진하지 말자. 구현해야 할 것들을 테스트 목록에 적고 모든 오퍼레이션의 사용 예들을 적는다. 그리고 만약 존재하지 않는 오퍼레이션의 경우 null을 반환하는 스텁(stub)을 만들고 리팩토링 목록을 적는다.

 

 

테스트 우선

테스트를 언제 작성하는 것이 좋을까?
테스트 대상이 되는 코드를 작성하기 직전에 작성하는 게 좋다.

 

코드를 작성하고 테스트를 만들지 않겠다는 목표로 테스트를 먼저 해야 한다고 생각하자. 

 

 

단언 우선

테스트를 작성할 때 단언(assert)은 언제 쓸까?
단언을 제일 먼저 쓰고 시작하라.

 

• 시스템 개발 시 무슨 일부터 할까? 완료된 시스템이 어떨지 알려주는 이야기부터 작성한다.
• 특정 기능을 개발 시 무슨 일부터 할까? 기능이 완료되면 통과할 수 있는 테스트부터 작성한다.
• 테스트를 개발할 때 무슨 일부터 할까? 완료될 때 통과해야 할 단언부터 작성한다.

단언을 먼저 작성하면 작업을 단순하게 만드는 강력한 효과를 볼 수 있다.

 

 

테스트 데이터

테스트할 때 어떤 데이터를 사용해야 하는가? 
테스트를 읽을 때 쉽고 따라가기 좋을 만한 데이터를 사용하라.

 

테스트 작성에도 청중이 존재한다. 데이터 간에 차이가 있다면 그 속에 의미가 있어야 한다. 

 

 

명백한 데이터

데이터의 의도를 어떻게 표현할 것인가?
테스트 자체에 예상되는 값과 실제 값을 포함하고 이 둘 사이의 관계를 드러내기 위해 노력하라.

 

명백한 데이터의 사용은 후에 코드를 읽을 내가 아닌 다른 사람들에게도 도움을 주며 다음으로 무엇을 해야 할지 쉽게 알 수 있게 해 줘 프로그래밍을 더 쉽게 만들 수도 있다.