일레클 Android TDD 도입기 (1/3)
안녕하세요, 일레클 서비스를 운영하는 나인투원 Mobile 팀에서 안드로이드 개발을 하고 있는 최정인입니다. ‘일레클 Android TDD 도입기’는 세 개의 포스팅에 걸쳐 작성될 예정입니다.
본 포스팅에서는 TDD를 도입하기까지의 배경, 그리고 본격적으로 TDD를 도입하까지 거쳐온 기나긴 과정들에 대해 소개합니다. 이어지는 두번째 포스팅에서는 팀원들과 다함께 테스트 코드 작성을 연습하기 위해 추진했던 리팩토링 세션의 진행 방식을 소개합니다. 그리고 세번째 포스팅에서는 실제로 TDD를 도입해서 개발을 진행한 과정을 소개합니다.
시리즈 전체 보기
일레클 Android TDD 도입기 (1/3) → TDD를 도입하기까지의 배경, 본격적으로 도입하기까지의 기나긴 과정
일레클 Android TDD 도입기 (2/3) → 리팩토링 세션을 통한 테스트 코드 작성 연습, 컨벤션 맞추기
일레클 Android TDD 도입기 (3/3) → 본격적으로 테스트 주도 개발 방식을 적용해서 스프린트를 진행한 과정
테스트 주도 개발(Test Driven Development)이란?
테스트 주도 개발(Test Driven Development, 이하 TDD)은 소프트웨어 개발 방법론 중 하나입니다. 특정 기능을 구현하기 위해 코드부터 바로 작성하는 것이 아니라, 해당 기능에 대한 테스트 케이스들을 먼저 작성하는 방식입니다. 아래 다이어그램에서 볼 수 있듯이, 소위 ‘Red → Green → Refactor’ 로 알려진 프로세스를 거치는데요.
예를 들어 계산기 어플리케이션을 구현한다면, ‘=’ 기호를 눌렀을 때 주어진 수식의 결과값이 나타나야 합니다. 즉 ‘=’ 기호를 누르면 실행되는 함수에서는 주어진 수식을 파싱하고 사칙연산을 수행해야 할 것입니다.
이 때 TDD 방법론을 적용할 경우, 함수의 내부 로직을 짜기에 앞서 “수식 ‘1+2’이 주어졌을 때 ‘=’을 누르면 결과값이 ‘3’이다” 와 같은 테스트 케이스들을 먼저 생성합니다. 그리고 나서 테스트 케이스들이 모두 통과하도록 함수를 작성합니다.
TDD의 필요성을 느끼게 된 계기?
작년 여름, 저는 신입의 패기로 ‘risky 리팩토링’들을 수 차례 진행했었습니다. Deprecated된 라이브러리를 전부 교체하는 작업, 중복된 코드들을 제거하기 위해 인터페이스화 시키는 작업 등.
이런 작업들은 변경되는 코드의 줄 수가 매우 많습니다. 더구나 그 때 당시 저희 mobile 팀의 리뷰 시스템은 지금보다 훨씬 체계가 부족했습니다. 브랜치 룰도, 커밋에 대한 컨벤션도, PR 템플릿도 모두 없었습니다. 그러한 상황에서 레거시 코드에 대한 이해도가 충분하지 않던 뉴비가 리팩토링을 한다는 것은 지금 떠올려도 정말 ‘risky’한 일이었습니다.
또한 코드 변경 사항이 많을 경우, 영향 받는 조건 분기들을 모두 테스팅해봐야 합니다. 다만 여기서의 테스팅은 수작업을 의미합니다. 유저의 상태를 서버 상에서 하나하나 바꿔주고 새로 빌드해서 확인하는 것이지요. 아마 네이티브 앱 개발을 해보신 분들은 아시겠지만, 빌드만 하는 데에도 상당히 오랜 시간이 걸립니다.
이렇게 개발 과정에서 테스팅을 하더라도, 배포 직전에는 QA를 따로 또 거치게 됩니다. QA 담당자들을 위해 개발자는 테스팅 시나리오 — 서버에서 어떤 값을 조작해야 하는지, 앱에서는 어떤 버튼을 눌러야하는지 등 — 을 모두 촘촘히 작성해야 합니다. 미리미리 구체적으로 적지 않는다면, 그만큼 배포 직전에 커뮤니케이션 리소스가 들기 때문입니다.
개발 과정에서도 테스팅을 하고 배포하기 전에도 QA를 했지만, 나중에 새로운 피쳐가 배포되면 또 깨지기도 합니다. “분명 QA를 했는데..”라는 생각으로 들여다보면, 기획자도 개발자도 미처 고려하지 못한 분기가 있곤 했습니다.
이런 일들이 반복되던 찰나, “테스트 코드를 작성하면 이 문제상황들이 개선될 수 있지 않을까?”, 하는 생각이 들었습니다. 참고로 저는 안드로이드에서 테스트코드를 짜 본 적은 없었지만, 예전에 웹개발 프로젝트를 하면서 react enzyme과 python unittest를 적용해본 경험이 있었습니다.
특정 버튼을 클릭했을 때는 어떤 url로 넘어가야 한다거나, 어떤 조건에서는 함수의 결괏값이 뭐가 나와야 한다거나. 이러한 부분들은 테스트 코드로 사전에 검증함으로써 많은 리소스를 줄일 수 있다는 생각에 그 때부터 안드로이드에서의 테스팅, TDD 방법론의 실무 적용, 테스트 코드 작성을 위한 툴과 컨벤션 등에 대한 리서치를 틈틈이 진행했습니다.
팀 내 consensus에 도달하기 위하여
TDD를 도입하기까지 정말 많은 어려움이 있었습니다. 테스트 코드를 작성하는 법, 각종 라이브러리를 서치하고 그를 활용하는 법 등 코드 레벨의 허들도 있었지만, 돌아보면 팀 내 consensus에 도달하는 과정이 가장 어려웠다고 생각됩니다.
TDD 방법론의 장점에 대해서는 온라인 상에 무수히 많은 글들을 발견할 수 있습니다. 잠재적 버그를 사전에 파악할 수 있다, 꼼꼼한 분기 처리가 가능하다, 테스트 케이스들을 통해 함수의 동작을 보다 쉽게 파악할 수 있다 등. 하지만 TDD는 ‘cost’가 크다는 것도 분명합니다. 테스트코드를 작성하고 커버리지를 채우는 과정에서 기존의 개발 시간보다 더 오래 걸리기도 하고, 로직이 수정될 때마다 테스트코드도 함께 수정해야 한다는 번거로움이 있습니다.
그렇기 때문에 아래 요소들에 대해 팀원들과 충분히 오랜 시간동안 논의를 진행해야 합니다.
왜 굳이 TDD를 해야 하나?
TDD를 도입하면 어떤 장점이 있나?
시기 상 지금 도입해봐야 하는 이유는 무엇인가?
‘TDD 합시다!’라고 무턱대고 주장하기보단, 리서치를 진행하면서 조금씩 소재를 모으다가 자연스러운 타이밍에 논의 주제로 꺼내는 것이 더 효과적입니다. 이를테면 일레클 소프트웨어 팀에서는 약 3~4주 단위로 티타임을 진행하는데, 그런 자리들에서 한 마디씩 꺼내는 것이죠. “xx팀은 혹시 테스트코드 작성 하고 계신가요? 어떻게 하고 계신가요?”
특히 초반에는 (리서치 → 시행착오 → 공유 → 문서화) 싸이클을 끊임없이 반복해야 하는데요. 네 가지 모두 중요하지만 저는 ‘공유’가 가장 중요하다고 생각합니다. 몇 주 어치의 리서치와 시행착오를 열심히 문서화한다고 해서, 다른 팀원들이 문서만 보고 한 번에 이해하고 파악할 수 있는 것은 절대 아닙니다. 오히려 매일의 progress를 조금씩 공유하는 것이 서로의 sync를 맞추는 데에 더 효과적입니다.
이러한 논의가 잘 이뤄지기 위해서는 건강한 커뮤니케이션 문화와 서로에 대한 신뢰자산이 필요합니다. 저희는 그리하여 이 맘때 쯤부터 ‘Mobile팀 데일리 스탠드업’ 미팅을 매일 15분씩 진행했습니다. 그리고 리서치와 시행착오의 기록들이 누적되었을 시점에 페어프로그래밍 세션들을 진행해서 서로의 싱크를 맞췄습니다.
마일스톤 정하고 타임라인 설정하기
TDD를 위해 지나온 기나긴 여정을 타임라인으로 그려보았습니다. 처음부터 각 마일스톤들이 정해지지는 않았다는 점을 강조하고 싶습니다! 일레클 Mobile팀 데일리 스탠드업 미팅을 통해 팀원들이 매일 조금씩 합의를 통해 방향을 다듬어 갔고, 차곡차곡 다음 마일스톤을 위해 달려갔습니다.
팀원들 모두 안드로이드 테스트코드에 경험이 없었기에 consensus에 도달하기까지도 오래 걸렸고, 리서치를 하는 과정 또한 고통스러웠습니다. 테스트 코드에 관련된 코드 레퍼런스를 찾기도 어려웠고, 적당히 취사 선택해서 우리만의 테스트케이스들을 만들어나가는 것도 어려웠습니다.
하지만 밑바닥부터 리서치하며 공식 문서를 읽는 연습, github 상에서 다른 개발자들의 코드를 읽고 좋은 practice들을 뽑아내는 연습을 압축적으로 할 수 있었던 좋은 기회였습니다! (저는 mockk 공식 문서를 하도 여러번 들어갔더니, 지금도 구글 창에 m이라고만 치면 https://mockk.io/ 가 뜹니다 😅)
혹시나 팀에 TDD를 도입하고 싶지만 뭐부터 어떻게 할지 모르겠어서 막막하시는 분들께 이 시리즈가 도움될 수 있다면 좋겠습니다! 이어서 두번째 포스팅에서는 팀원들이 다함께 테스트 코드 작성을 연습할 수 있도록 추진했던 리팩토링 세션의 진행 방식을 소개하겠습니다. 🙂
시리즈 전체 보기
일레클 Android TDD 도입기 (1/3) → TDD를 도입하기까지의 배경, 본격적으로 도입하기까지의 기나긴 과정
일레클 Android TDD 도입기 (2/3) → 리팩토링 세션을 통한 테스트 코드 작성 연습, 컨벤션 맞추기
일레클 Android TDD 도입기 (3/3) → 본격적으로 테스트 주도 개발 방식을 적용해서 스프린트를 진행한 과정
