[개발자 일상] 어떻게든 TDD
16 Jun 2019
2년 반동안 같이 성장했던 스타트업을 그만두고 2개월 가량 마음을 추수리고 있던 중 지인이 같이 일하면 좋겠다는 제안에 파킹 클라우드에 입사하게 되었습니다. 생각보다는 좌충우돌이고 정말 빠르게 성장하는 회사에 같이 협력하게 되었다는 기쁨도 잠시 역시 업무는 실전입니다.
유지 보수 업무
개발자는 처음부터 새로운 제품을 개발하는 것이 아니라면 대부분은 유지보수 업무에 많은 시간을 할애합니다. 저 또한 파킹클라우드에서 개발되어있는 백오피스 통합 프로젝트를 유지보수하는 업무를 맡게 되었습니다. 언어는 PHP
, 프레임웍은 Slim
이었습니다. 제가 백오피스 프로젝트를 받으면서 놀란 점이 있습니다. 프론트엔드(FE
)와 백엔드(BE
)의 명확한 구분을 하고 있다는 점이었습니다. 웹 서버 어플리케이션(WAS)가 변수를 바인딩하는 렌더링 페이지 까지 넘겨주는 방식으로 개발되는 경우가 많은데 그렇지 않았습니다.
이전 스타트업도 실력이 있는 FE
개발자 분이 들어 오기 전까지는 벡엔드에 의존성이 높은 렌더링 페이지를 제공했었습니다. FE
개발자 분 입사 후에 개발했던 코드도 다 리팩터링하고 조금 더 깔끔해졌습니다. 그렇게 의존성이 낮은 시스템 구조의 장점을 잘 알고 있었기 때문에 반가웠습니다.
두려움
반가움도 잠시 유산(Legacy) 코드는 언제 만나도 유산 코드였습니다. 많은 개선이 필요해 보였고 의존성이 상당히 높은 프로젝트 구성을 가지고 있었습니다. ‘아, 이거 리팩토링만 해도 상당한 시간이 걸리겠는데..’라는 생각을 했습니다. 그리고 실제로 업무를 진행하기 위해서는 안정 장치
가 필요했습니다.
단위 테스트
불가능
코드를 다루는 개발자에게는 테스트 코드라는 안정 장치가 바로 단위 테스트
로 만들어진 테스트 코드들입니다. 하지만 제가 사용할 수 있는 단위 테스트
코드는 하나도 없었습니다. 이 유산 코드를 받고 나서 그래도 다행인 것은 프론트엔드와 완전한 분리가 있었던 것입니다. 프로젝트 구성상 단위 테스트
를 작성하기 매우 어려운 상황이었습니다. (물론 Slim에서 TDD를 기본적으로 구성해주지만 사용하지 않았고 시간이 지나면서 엔트로피
가 매우 높은 사황이어서 TDD를 할 수 없는 상황이었습니다.) 그리고 덤으로 해당 코드를 잘 알고 있는 팀원들은 없는 그런 어려운 상황이었습니다.
MVC 패턴을 사용했지만 Controller의 함수에서 모든 것을 처리하고 있어 컨트롤들은 적게는 3000 line 많게는 6000 line이고 레퍼런스가 지원이 어려운 PHP 특성상 변수 하나 확인하는 것도 힘들었습니다. 이렇게 코드 자체가 크기도 하지만 의존성이 높다보니 단위 테스트
자체가 불가능 했습니다.
단위 테스트
대안
Feature 테스트 코드 작성하자
저는 Laravel 프레임웍을 이용하여 개발을 해왔고 많은 노하우를 그 프레임웍에서 가져올 수 있었습니다. 그중에 feature test
라는 개념이 있었습니다. API 호출에 input
과 output
을 확인하는 테스트입니다. 그래서 이 방법을 도입하면 단위 테스트를 하지는 못할 지언정 API가 제대로 동작하는지 확인할 수 있다고 생각했습니다.
Feature TEST 작성기
Slim 프레임웍에서도 Feature 기반의 테스트를 작성할 수 있었지만 단위 테스트
가 불가능한 상황과 마찬가지로 Feature 테스트도 작성이 불가능했습니다. 결과적으로 찾아 낸것을 postman
를 활용한 시나리오 기반 테스트 코드였습니다.
현재 모든 API를 커버하는 Feature 코드는 작성되는 것은 정말 오래걸리는 작업으로 예상되고 있습니다. API 하나 리팩터링하는데에 하루(4시간 이상) 정도 소요되고, 테스트 하나 작성하는 것도 하루 정도 소요 되어서 하나를 하는데 이틀 정도라는 어마어마한 시간이 드는 것을 확인했습니다. (우선 서비스 로직 혹은 비지니스 로직을 모르니…)
위의 그림을 보시면 출고 요청서 부분의 시나리오 테스트를 모두 통과한 것을 확인할 수 있습니다. Feature 테스트를 작성하는 것은 postman 툴을 이용하고 있습니다.
또한 컬렉션(collection)과 환경(env)를 코드로 관리하고 newman을 활용 하여 피처테스트를 거치면 프로젝트를 스테이징에 자동으로 배포 하도록 구성하였습니다.
하나의 도메인의 작은 부분에서 안정장치이기는 하지만 좀 더 자신감 있게 개발 할 수 있게 되었습니다.