클린 코드를 읽으면서 로버트 C. 마틴은 TDD가 개발에 있어서 중요함을 넘어서 당연히 시행되어야 한다고 한다.
하지만 지금까지 TDD에 대한 막연한 생각은 있었지만 이 기회에 공부하고 적용해보자.
발단
작년부터 나는 초기 IT 스타트업에서 서버 개발자로 일하는 중에 있다. 개발을 하면서 이전에 작성했던 내 코드의 아쉬운 점이 보이면서 내 코드 품질과 팀원의 코드 품질을 높이고 올바른 코드 리뷰 문화를 자리 잡게 하기위해 클린 코드를 읽게 되었다. (클린 코드 정리)
그리고 중간에 업무 중에 서비스 코드를 변경하는 일이 생겼는데 다음날 예상치 못한 부분에 버그를 찾았다. 전날에 서비스 코드 변경에서 변경된 부분이 문제가 되었다. 이런 부분을 어떻게 모두 고려하면서 코드를 짜고, 변경할 수 있겠는가?
정답은 TDD에 있다.
그렇게 TDD에 대한 공부를 시작했다.
두권의 책 (테스트 주도 개발과 테스트 주도 개발 시작하기)을 읽었고, 유튜브 강의와 강연, 다양한 블로그 글들 그리고 AI 챗봇의 도움을 받으며 공부를 진행했고, 정리해보려고 한다.
TDD?
그렇다면 TDD를 왜라는 질문에 어떻게 대답해야될까? 공부를 해보니까 뭐부터 얘기해야 될지 모를 정도로 장점은 많다.
1. 잦은 리팩토링으로 깔끔한 코드
2. 필요한 기능만 구현
3. 다른 잠재적 버그 확인
4. 시간 단축
내가 정리한 TDD의 가장 큰 장점 4가지이다. (거를 타선이 없다.)
시간 단축에 대해 얘기해보자
출처 : 12 best practices of agile development method XP
위 이미지는 개발 애자일을 갖추기 위한 12가지 덕목이다. 파란원 -> 초록원 -> 빨강원 의 순서대로 이루어져야 개발 애자일이 유지된다. 파란원은 작은 팀의 개발팀이 지켜야 하고, 초록원은 전체 개발팀, 빨강원은 전체 팀이 지켜야한다.
하지만 많은 팀들이 애자일을 실패한다. 이유가 파란원부터 지키지 못해서 개발 애자일이 올바르게 이뤄지지 않다는 것이다. 파란원부터 단단히 중심을 잡고, 초록원, 빨강원 순서로 나아가야 하는데 많은 팀들이 파란원을 갖추지 못한 채 다른 원을 포커싱하다보니 코드가 쌓여가면 의미없는 버그가 자꾸 생기고, 개발 프로세스는 복잡해지며, 스프린트의 단위는 늘어나면서 애자일이 무너진다.
개발 애자일을 올바르게 적용하는 팀이 되고싶다? -> TDD를 올바르게 시작해보자.
시간이 지나면 테스트 코드는 쌓일 것이며, 개발 중간중간 누르는 전체 테스트 실행은 우리 서비스의 많은 잠재적 버그를 발견하게 하여 시간을 단축시킬 것이다.
어떻게 쓰는건데?
간단하다.
1. 실패하는 테스트 코드를 작성
2. 테스트를 통과시킬 만큼 구현
3. 초록불 확인
4. 리팩토링
너무 간단하다. 처음 봤을때 놀랐다. 책을 보면서 실습을 하는데 그냥 값을 하드코딩으로 만들고, 이후에 리팩토링을 한다. 생각보다 너무 간단하다. (왜 테스트 주도 개발이라고 옛날부터 알면서 겁먹고 알아볼 생각조차 하지 않았을까..) 이렇게 단위 테스트를 만들때마다 리팩토링과 단위 테스트를 통과하기 위한 정도의 코드는 1. 리팩토링으로 깔끔한 코드, 2. 필요한 기능만 구현의 TDD 장점의 결과물이 된다.
디테일
- 자동화된 테스트를 만든다.
- 격리된 테스트
- 쉬운 테스트에서 어려운 테스트로 진행해라
- 시작전 작성할 테스트 목록을 모두 적어둔다. (매뉴얼로 만들어 후에 작업에도 사용)
- 대상 코드를 작성하기 직전에 작성하는 것이 가장 좋다.
- Assertions를 제일 먼저 쓰고 시작해라
- 쉽고 따라가기 좋을만한 데이터를 사용해라 (후에 더 자세히 알아보자)
- 여러 의미의 동일한 상수를 쓰지마라
- 구체적인 데이터는 상수를 선언해라
내가 정리한 디테일은 이정도다.
마무리
그리고 모든 내가 참고한 곳에서는 강조한다. TDD는 수련이 필요하다고..
계속된 수련이 필요하다. 그 속에서 가장 중요한 점을 잊지 말자.
1. 지속적인 코드 정리
2. 빠른 피드백
3. 테스트를 통과할 만큼만 코드 작성
4. 설계대로 진행
그럼 TDD를 통해 우리 조직의 애자일 문화를 지켜보자!!!
(다음 포스팅은 위의 내용을 지키며 TDD 예제 코드를 만들어보자.)
