TDD 도입하고 개발해보며 체득하기

최근에 QR코드를 사용하여 스마트오더를 개발하는 프로젝트를 진행하고 있습니다.

프로젝트에서 제가 맡은 파트는 "메뉴 옵션" 개발입니다

 

지금까지 했던 프로젝트의 백엔드는 혼자 진행하였고 규모도 크지 않아 테스트 코드를 하지 않아도 어느 정도 품질이 보장되었지만(MVP 테스트 진행), 이번 프로젝트는 8월까지 MVP 개발을 끝내고 실제 소상공인들이 사용할 서비스로 어느 정도 규모가 있었기 때문에 품질 보장이 되어야 했습니다.

 

또한, 이미 릴리즈된 애플리케이션은 그걸로 끝나지 않고 지속적으로 새로운 기능을 추가해야하며 코드들은 처음과 다른 모습이 되어가게 됩니다. 기존에 있던 코드들의 동작이 변하지 않았는지 보장할 수 있어야 했기에 테스트 코드의 작성은 필수입니다.

 

TDD 도입 이유

백엔드 팀원분이 TDD는 처음 도입해 보는 것이라고 했습니다. 그래서 기존에 TDD로 어떻게 개발했는지 물어볼 수 없었고, TDD 도입 이유 또한 듣진 못했지만, 나름대로 의미를 부여하는 게 하는 맛도 나고! 얻어가는 것도 많다고 생각하여 의미를 부여해 봤습니다.

 

TDD의 궁극적인 목표는 테스트가 아니라 작동하는 깔끔한 코드라고 합니다. TDD의 아이러니 중 하나는 TDD가 테스트 기술이 아니라 분석 기술이며, 설계 기술이기도 한다는 점입니다.

 

작동하는 깔끔한 코드가 무엇인지 명확하게 정의하기는 어렵지만 우리는 직관적으로 무엇이 깔끔한 코드인지 아닌지 알고 있습니다. 바로 "변경이 쉬운 코드"입니다.

 

즉, 테스트를 먼저 작성하게 되면 변경이 용이한 코드로 이끈다는 것을 의미합니다. 테스트가 어려운 설계는 곧 변경이 어려운 코드일 테니까요.

 

요구 사항

테스트 코드를 작성하기 전에 테스트 코드를 작성할 파트를 보고 어떻게 작성해야 하는지 생각해 봤습니다.

github project

 

 

우선 Request, Response에 대한 명세가 없었기 때문에 먼저 명세를 작성한 후 테스트 코드를 작성했습니다.

 

결과

테스트 코드 작성 & 로직 작성만 꼬박 5일이 걸렸습니다.

 

이렇게 오래 걸렸던 이유와 이를 통해 얻은 인사이트는 다음과 같습니다.

 

문제 1: 기존의 테스트 방식과 달랐기 때문에 오래 걸렸다.

어쩔 수 없는 부분이라고 생각합니다. 일반적인 개발 방식에 익숙해져 있기 때문에 반복하여 체득하고 자신만의 효율적인 방법을 찾는 방법밖에 없다고 생각합니다.

 

문제 2: CRUD에 대한 모든 테스트 코드를 작성한 후 CRUD 비즈니스 로직을 작성하였다.

[테스트 코드 작성] -> [비즈니스 로직 작성] 흐름에만 집중했기 때문에 발생한 문제라고 생각합니다.

 

해당 흐름의 가장 큰 문제점은 TDD의 장점인 빠른 피드백을 받지 못하는 것이었습니다. 또한 테스트 코드 수정 시 작성된 테스트 코드 전체를 수정해야 했기 때문에 효율적이지 못했습니다.

 

변경할 점

1. TDD의 원칙에 더욱 충실하게 작성하기 위해 [Create 테스트 코드 작성] -> [Create 로직 작성 흐름]으로 작성하기

2. 작은 단위로 시작하여 초기 개발 속도 높이기

 

 

그래도 우여곡절 끝에 테스트 작성 코드 PR 날렸다!

 

느낀 장점

TDD로 개발하니까 재밌습니다. 예외를 찾는 과정도 재밌고 작성한 테스트 코드에 얼른 성공 코드를 작성하고 싶어서 재밌었습니다.

기능이 애매한 부분 (ex) 메뉴는 하나의 카테고리 밖에 없는가?))을 비즈니스 로직을 작성하기 전에 발견하여 초기에 수정할 수 있었습니다!

 

 

 

개인적으로 생각하는 테스트 코드 작성의 가장 힘든 점은

테스트 코드를 작성하는 습관인 것 같다.

나중에 숨 쉬듯 테스트 코드를 작성할 만큼 몸에 체득하자.

아자아자 파이팅!

끗