올해 1월부터 사내에서 ⌜Test-Driven Development : By Example⌟책을 이용해 TDD에 대하여 알아보고 실제로 업무에 적용해보면서 우리 조직에 가장 적합한 형태의 Best Practice를 찾기 위한 스터디를 진행하고있다.

⌜Test-Driven Development : By Example⌟ 책은 본격적인 목차에 들어가기 전 저자의 글, 역자의 글, tdd 수련법 등 알찬 부록들로 시작한다. 이 중 저자의 글에서는 앞으로 이 책에서 다루게 될 TDD를 전반적으로 오버뷰해볼 수 있는 중요한 내용들이 들어가있어서 이 부분에 대한 정리로 이 책의 리뷰를 시작해보려한다. 그 전에, 이전까지의 나의 테스팅 경험을 간단히 소개해보겠다.

이전까지 나의 테스팅 경험

개발자 준비를 하며 다녔던 부트캠프에서 프로젝트를 진행하면서 테스트를 작성했었다. 프론트엔드와 백엔드의 테스트 코드를 모두 작성해보았는데, 프론트엔드에서는 리액트 테스팅 라이브러리를 이용한 UI테스트, cypress를 이용한 E2E 테스트를 작성했었고, 백엔드에서는 mocha와 chai를 이용한 API 테스트를 작성했었다.

물론, 공식문서를 더듬더듬 읽어가며 간단하고 쉬운 테스트를 위주로 작성해본 것이었지만, 프론트엔드에서의 테스팅과 백엔드에서의 테스팅의 차이를 느낄 수 있었다.

프론트엔드에서의 테스팅에서 가장 어려웠던 점은 ‘무엇을 테스트해야하는가’였다. 프론트엔드에서 작성할 수 있는 가장 간단한 테스트는 UI에 특정 텍스트가 보여지는지를 검증하는 UI 테스트였는데 작성하면서도 이 테스트가 의미가 있을까? 하는 의문이 들었었다. 코드 에디터 옆에 로컬에서 코드를 실행한 브라우저창을 띄워놓으면 코드를 작성하는 동안 실시간으로 알맞은 UI가 화면에 보이는지 확인할 수 있는데 이걸 시간을 들여 테스트로 작성해야하는걸까?하는 생각을 했던 것 같다. 반면 백엔드의 경우 기능단위로 각각의 함수가 만들어지고 해당 함수들의 input과 output이 명확해서 무엇을 테스트해야하는지도 쉽게 파악할 수 있었던 것 같고, 이 테스트를 작성하는 것이 추후에 로직을 리팩토링하는 경우에도 유용하게 쓰일 수 있을 것 같은 생각이 들었다.

TDD에 대하여

테스트 주도 개발의 궁극적인 목표는 작동하는 깔끔한 코드(clean code that works)이다.

어떻게 하면 작동하는 깔끔한 코드를 작성할 수 있을까? 그것은 자동화된 테스트로 개발을 이끌어나가는 것이다.

테스트 주도 개발의 규칙은 다음과 같다.

• 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.
• 중복을 제거한다.

위 두 가지 규칙에 의해 프로그래밍 순서는 다음과 같이 결정된다.

1. 빨강: 실패하는 작은 테스트를 작성한다. 처음에는 컴파일조차 되지 않을 수 있다.
2. 초록: 가능한 빨리 테스트가 통과하게끔 만든다. 이를 위해 어떤 죄악을 저질러도 좋다.
3. 리팩토링: 일단 테스트를 통과하게만 하는 와중에 생겨난 모든 중복을 제거한다.

TDD에 대한 이야기를 할 때 또 중요한 한 가지는 자신감에 관한 이야기이다. TDD 방식으로 프로그래밍을 하면 한 단계 한 단계 기능을 구현해나가면서 이전에 구현한 기능에 대해서는 다시 뒤돌아볼 일이 없다. 왜냐면 테스트가 나의 코드를 보장해주기 때문이다.

일단 테스트 하나를 작동하게 하면, 그게 지금 현재 그리고 앞으로 영원히 작동할 거라는 걸 알 수 있다.

이러한 자신감은

• 내가 망설이지 않고 코드를 작성할 수 있게 해주며,
• 보다 더 적극적으로 커뮤니케이션하고 피드백을 받을 수 있게 해주며,
• 나를 여유롭게 만들어준다.

내가 작성하는 코드에 자신감을 가진 여유 넘치는 개발자가 되기 위해여.. 테스트를 작성해보자.

아직은 이 프로그래밍 방식을 업무에 어떻게 적용할 수 있을지 잘 감이 잡히지 않는다. 그래서 챕터1. 화폐예제를 자바스크립트로 따라서 실습을 해보면서 TDD로 생각하는 법을 익혀보려한다. 다음 포스팅에서 TDD를 직접 실습해본 결과물을 공유하고 그 과정에서 배운 점, 느낀 점들을 공유해보겠다. 🤓