회고 : 두번째 프로젝트를 TDD로 진행하며... #2
TDD로 진행한 내용 정리, 소감, 에피소드
#시작하기 전에
이 글 은 진행했던 TDD프로젝트의 회고이다. TDD를 설명하는 글은 아니다.
브런치의 글은 카피가 안되고 소스코드를 첨부하기에 적절하지 않아 Medium 에 글을 같이 쓰려한다.
Medium의 글링크를 첨부한다.
TDD로 진행한 내용 정리
앱의 요구사항을 먼저 정리하고. 정리된 요구사항을 화면 및 기능별로 분류한뒤, 테스트 코드를 작성했다.
실제 작업한 내용을 일부 정리했다.
1. 요구사항 정리.
- 물품의 입력 -> DB에 저장
- 물품의 삭제 -> DB에서 삭제
- 물품의 수정 -> DB에 업데이트
- DB에 물품이 입력되면 리스트에 반영.
2. 실패한 테스트 작성
테스트 코드 Gist 링크
https://gist.github.com/tilltue/d1459b06e0f00ee70bd82f489f646fa8
3. 구현 ( 테스트 성공 )
4. 리펙토링
위 과정중에 가장 힘든 과정은 2번이었다. 테스트 코드를 짤때 요구사항을 어떻게 구현할지 먼저 상상하고, 테스트를 작성하게 됐는데 이 과정이 가장 힘들었다.이 과정을 잘못하면 3번 과정중 다시 2번 과정으로 돌아가 되풀이 하는 경우가 발생했다. ( 이미 작성한 테스트 코드의 수정. )
통계로 정리한 진행 내용
목표로 한것들을 대부분 달성했다.
- TDD의 기본 과정을 지키며 코딩하기.
- 입력가능한 모든 UI입력에 대한 테스트 작성
- code coverage 100%달성.
공부도 많이 되고, 많은 것을 얻을수 있었다. 인포그래픽으로 정리했다.
활용 기술
작업된 분량 비교 ( 구현 코드 - 테스트 코드)
Test 수행 및 Code coverage 내용Coverage 100% 는 중요한 수치는 아니지만 목표로 한 것이었기에…
두번째 프로젝트를 TDD로 수행하고 느낀점
첫번째 프로젝트를 TDD로 할때는 재밌었다. 뭔가 새로운 방법을 배워나가는 배움의 즐거움이 있었고, 각 과정들을 처음 해보기에 흥미롭고 재밌었다.
이번 프로젝트는 힘들었다. TDD는 너무 어려웠고, 자괴감이 들때가 많았다. 요구사항에 맞춰 상상해서 작성한 테스트가 실제로는 적절하지 않아 다시 테스트를 작성하는 경우들이 그러했다.
테스트를 작성하지 않은 코드가 발견했을때, 그 코드로 인해 버그를 발견했을때, 만약 놓치지 않고 테스트를 작성했다면 버그를 방지할수 있었을텐데… 등 테스트를 잘 짜지 못한 것에 대해 자괴감이 들었다.
아직 테스트 작성에 대해서는 더 공부하고 경험해봐야 할것 같다. ( 한참 멀었다 )
이번 프로젝트를 통해 개인적으로 얻을수 있었던 것들은 아래와 같았다.
(지극히 개인적인 의견이다.)
1. TDD를 통해 불필요한 구현을 막을수 있었다.
- 요구사항을 먼저 생각하고 코드를 상상하는 과정에서 필요없는 구현을 막아주고, 코드가 해야할일을 명확히 할 수 있었다.
2. 실제 팀 프로젝트에도 TDD를 도입하게 되었다.
- 아직 초기 단계이고, 모든 코드를 TDD로 작성하고 있지는 않는다
- 자율적으로 진행하고 있다. iOS 개발을 두명이서 진행하는데, 동료도 TDD를 공부하고 있었기에 가능했다.
- 만약 이 전 프로젝트부터 TDD에 대한 학습을 계속 해오지 않았다면 팀 프로젝트에 TDD를 할 엄두를 내지 못했을것 같다.
3. 디자인 공부를 많이 하게 됐다.
- 테스트하기 좋은 코드에는 좋은 디자인이 필요하다. 때문에 디자인에 대해 더 많이 고민하게 되고 공부가 더 필요했다.
4. 테스트 코드는 개발자의 가장 기본적인 책임은 아닐까? 라는 고민을 하게 되었다.
- 이건 TDD 가 아닌 테스트 코드 작성에 대한 이야기이다.
- 테스트 코드를 통해 요구사항 구현에 대한 가장 기본적인 책임을 다했다고 이야기 할수 있지 않을까? 통제된 상황내에서는 항상 같은 결과를 보장할수 있는 거니까.
- 하지만 의무감에 짜여진 테스트 코드가 되어서는 안된다고 생각한다.
TDD를 하면 이전에 진행하던 개발방식에 비해 갑자기 드라마틱한 효과를 얻게 된다고 이야기 하고 싶진 않다.
사람에 따라서는 TDD로 개발하는 것이 어쩌면 독이 될수도 있다고 생각한다.
또, TDD를 혼자 학습해야 하는 환경이거나, 같이 할수 있는 동료가 없을때에도 힘든 길을 걸어야 한다고 생각하기에 쉽게 권하고 싶지도 않다. 하지만, 개인적으로는 TDD는 분명 좋은 영향을 줄수있는 개발 방법이라고 생각한다. 적어도 해보지 않고 TDD의 좋고, 나쁨 혹은 옳고, 그름을 판단하지는 말아야 한다고 생각한다. 적어도 공부를해보거나, 가능하면 한번 시도해본뒤에 판단해보기를 추천하고 싶다.
약 1년간 TDD를 공부해왔는데, 무엇보다 현업 프로젝트에 TDD를 도입하게 되었던 것이 가장 큰 수확이다. 개인 프로젝트에서 많이 연습한 내용을 바탕으로 이제 현업 프로젝트에서 TDD를 수행할텐데, 이 과정에서 얻을수 있는 것들이 어떤 것들이 있었는지, 회고할 날을 기대해 본다.
에피소드
(사족 =.= 참고로 재미없음... )
약 7개월간 이 프로젝트를 진행했는데, TDD는 정말 힘들었다. 종종 테스트코드를 생각하다 잠들곤 했었다.
언젠가 이런일이 있었다.
잘못 작성한 테스트 코드를 수정하다가 새벽에 잠이 들었는데 꿈에서 테스트 코드를 잘못 작성하는 꿈을 꿨다. 전날 미세먼지가 심해서 그랬는지 기침을 심하게 하다가 깼는데, 아내가 물을 한 잔 준다고 거실로 나가는걸 따라 가면서 “내가 테스트 코드를 잘못짜서 그래… “ 라고 중얼거렸다고 한다. 아침에 듣고 어찌나 웃기던지…
마찬가지로 한번 더 이런일이 있었는데 꿈에서 또 테스트를 잘못짜고 괴로워하다가 깼다. 그런데 엄청나게 허기가 몰려왔다. 뭐라 표현하기 힘들정도로 엄청난 허기가… 소파에 앉아 식빵을 게걸스럽게 먹고 다시 잠들었다. 괴로움이 허기를 불러왔나 보다.
TDD는 어렵고 힘들다고 생각한다. 아직 내가 실제 회사 프로젝트에서 TDD를 제대로 수행할수 있을지는 잘모르겠다. 계속 공부가 필요할것 같다.
마침.
