[번역] 테스트가 없는 앱을 이용하여 TDD를 배우는 방법

• 이 번역글은 Justin Weiss의 포스팅을 번역한 글입니다
• 오류 지적 및 피드백은 언제나 환영합니다. 댓글이나 메일로 알려주세요

당신은 자신이 만든 앱을 보고 매우 흥분한 상태이다. 한가지 문제가 있다는 점만 빼고 - 테스트를 전혀 작성하지 않았다는 점 말이다. 당신은 TDD(Test-Driven Development) 방법론을 적용하여 코드를 쓰고 싶었지만, 어디부터 시작해야 할지 전혀 몰라서 막혀버렸다. 어디부터 시작해야 할 것인가? 어떻게 하면 테스트가 없는 앱을 가지고 TDD를 이용한 앱을 작성할 수 있을까?

이미 작성한 코드를 테스트하라

당신은 테스트가 없는 코드 뭉치를 가지고 있다. 그렇다고 당장 기존의 코드를 가지고 테스트를 작성할 수 없다는 뜻은 아니다. 이미 가지고 있는 코드를 테스트하는 것 부터 시작해보라. 기대하던대로 코드가 작동하는지 확인해보는 것이다.

이건 TDD가 아니다. 그러나 이미 존재하는 코드를 테스팅하는 것은 TDD를 배우는데 도움을 줄 것이다.

• 예외적인 경우나 에러가 발생하는 조건에 대해 생각하는 연습을 하게 된다

  모든 가능한 입력을 테스트하느라 수 년을 허비하지 않고 테스트를 작성하기 위해서, 당신은 보통 코드의 어느 부분에서 문제가 발생하는지 생각해야 한다. 만약 문자열을 받는 메서드를 테스트한다고 할 때, 대신 심볼을 넣으면 어떤 일이 생길 것인가? nil 을 넣는다면? 혹은 숫자를 나누는 함수를 테스트한다면, 0을 입력하는 경우에 대한 테스트를 하는 것이 좋다. 하지만 아마 1과 2를 테스트 할 필요는 없을 것이다.

  당신은 충분한 테스트를 작성한 뒤에 메서드의 어느 부분에서 문제가 발생할지 예측하기 시작할 것이다. 그리고 한번 TDD를 시작하면 이 기술을 이용하여 탄탄한 테스트를 작성할 수 있을 것이다. 이 테스트들은 예외 사항들을 더욱 잘 처리하도록 코드를 강제하는 역할을 한다.

• 짜임새있는 테스트를 작성하는 연습을 하게 된다

  이미 작성한 코드에 대한 테스트를 작성한다면, 이 테스트들을 구조화하는 다른 패턴들을 시도해볼 수도 있다. 테스트하고자 하는 코드는 이미 있다. 그러니 당신은 테스트 자체, 그리고 이 테스트가 어떤 식으로 작성되어야 하는지에 대해 집중할 수 있다. 그리고 한번 몇몇 좋은 패턴들을 익히고 나면 당신이 기댈 코드가 없을 때에도 더 좋은 테스트를 작성할 것이다.

• 코드를 테스트하기 힘들게 하는 요소들을 발견하게 된다

  테스트들을 작성할 수록 점점 시스템 어느 부분이 테스트하기 제일 어려운지 느끼게 될 것이다. 그런 부분들을 알아차리게 되면 그 부분을 리팩터링이 필요한 부분이라고 표시해둘 수 있다. 더 나아가 처음부터 더욱 테스트하기 좋은 코드를 작성하기 시작할 것이다.

  테스트하기 좋은 코드가 어떤 식으로 생겼는지 알기 시작하면, 그 지식을 기반으로 TDD하기 쉬운 API를 개발할 수 있으며 더욱 빨리 앱을 개발할 수 있을 것이다.

TDD에 익숙해지기(Ease into TDD)

‘테스트를 나중에’ 기법을 TDD를 배우는데 도움이 되는 기술로 사용할 수 있다. 하지만 여전히 당신 앱의 일부에 TDD를 적용하고 싶을 것이다.(역주: 테스트를 먼저 작성하고 기능을 개발하는 것을 의미하는 것이라 추정합니다) 그리고 기존의 코드를 가지고 TDD에 익숙해지는 간단한 방법이 있다: 회귀 테스트를 작성하는 것이다

회귀 테스트는 이미 확정한 코드를 부수는 것을 억누른다. 아이디어 자체는 아주 간단하다. 당신이 버그를 발견할 때마다, 그 버그를 다시 만들어보기 위해 브라우저에서 여기저기 클릭해보는 대신에:

• 버그를 재생성하기 위해 실패하는 테스트를 작성하라.
• 테스트를 실행하라, 그리고 그 테스트가 확실히 실패하는지 확인하라 (왜냐면 버그는 아직 존재하니까).
• 가능한한 가장 간단한 방법으로 버그를 수정하라.
• 테스트를 실행하라, 그리고 테스트가 통과하는지 확인하라.
• 만약 필요하다면 당신이 수정한 방법을 리팩터링하라.

이 방법은 새 시스템을 밑바닥부터 TDD로 개발하는 것 보단 훨씬 쉽다. 왜냐면 이미 작성된 코드를 단지 테스트 주도적으로 바꾸기만 하는 것이기 때문이다. 그리고 “Red, Green, Refactor” 라는 TDD의 핵심적인 루프를 습관화하게 된다. 그리고 이쯤부터 당신의 TDD는 테스트가 없는 상태에서 바로 TDD로 개발하는 것에 가까워지게 된다.(And from here, TDD is a shorter step away than trying to go straight to TDD from no tests.)

테스트가 없는 상태에서 TDD로

테스트가 없는 앱은 그렇게 나쁜 출발점은 아니다. 이미 작성된 코드를 테스트할 때, 당신은 좋은 TDD 테스트를 작성하기 위해 무엇이 필요한지 많이 배우게 될 것이다. ‘테스트를 나중에’ 하는 것은 시작부터 TDD로 개발하는 것 보다 쉽다. 왜냐면 아직 어떻게 디자인해야할지 모르는 API들을 상상할 필요가 없기 때문이다. 그리고 자신의 앱에 한번 TDD를 도입하기로 결정했다면 회귀 테스트를 통해 익숙해질 수 있다.

그러니 만약 당신이 상상하고 있는 시스템에 TDD를 어떻게 도입해야 할 지 모르겠다면, 계속 테스트를 작성하라. 비록 코드를 먼저 써야 하더라도 말이다.

번역 후기

2017년 첫 번역은 TDD에 관한 글입니다. TDD 혹은 BDD(Behavior Driven Development)가 개발 방법론에 있어서 절대적인 진리는 아닐 겁니다. 다만 많이 권장되는데는 이유가 있겠지요. 저는 간단하게 TDD가 확장성, 유지보수성에 큰 도움이 된다고 인지하고 있습니다.

제 자신도 아직 실력이 미천하여 코드 없이 테스트를 작성한다는 것에 큰 두려움을 느끼면서 지내왔습니다. 최근에야 일부 기능에 대해 예측되는 결과를 먼저 테스트로 작성하고, 이후에 실제 기능을 작성하여 잘 작동하는지 확인하는 수준에 불과합니다.

그러다가 마침 기존에 작성한 코드를 이용하여 TDD를 배워나가는 과정에 대해 간단한 포스팅이 있어 이렇게 소개를 하게 되었습니다. 음.. 당장은 기존의 코드를 이용하여 테스트를 작성하는게 꽤 부끄럽지만 (왜냐면 테스트를 작성할 것도 없이 손대야 할 부분들이 수두룩하게 보이니까요) 이런 방식으로 약간 우회하여 TDD를 습득하는 방법도 있겠지요.

그럼 모두 2017년 한해에도 좋은 테스트 + 테스트를 통과하는 좋은 코드 작성이 잘 되시길 바랍니다 :)

(추가) 피드백에 의해 ‘You’ 라는 단어의 직역이 너무 많이 들어간 것 같아 조금 수정하였습니다. 확실히 번역할 때 ‘당신’ 이라는 단어가 일일이 들어갈 필요는 없겠네요. 좋은 피드백을 주신 @initNirvana 님께 감사드립니다.