코드를 확정하는 단계이다. release version이 바뀌지 않는 한, 웬만해서는 바뀔 일이 거의 없는 상황이라는 뜻이다. 우선 왜 리팩터링이 되어야 하는지를 먼저 논하고, 리팩터링 이후에는 왜 바뀔 일이 거의 없는지에 대해 설명하고자 한다.
🧐 왜 리팩터링 되어야 하는가?
기존의 CRUD 로직들은 Pagination의 성능 개선을 위한 역정규화 필드 추가로 인해 변질되었다.
코드 품질을 위한 에너지를 최소화 했었음 → 확정 이전에는 언제는 변경 가능성이 존재하기 때문이다.
로직들에 대한 Validation에서 누락 가능성이 존재하기 때문이다.
🧐 그럼 왜 리팩터링 이후에는 코드를 확정하는가?
추가적인 개발로직으로 인한 변경 가능성이 적기 때문이다. 기획측으로부터의 추가 요구사항이 있지 않는한, 구현 단계에서 구조나 로직이 변경될 일은 크게 없을 것으로 본다. 가령, Pagination 성능 이슈로 인한 엔터티 구조의 확장으로 인해 CRUD가 변질되는 등의 상황이 존재하지 않다고 확정하는 것이다. (변하지 않는 소프트웨어는 없다. 하지만 특정 한 버전 내에서의 비즈니스 로직은 변경 가능성이 적다. 만약 변경 가능성이 높다면 잘못된 설계가 아닐까…)
이는 ROI를 고려했을 때 적정 수준에서 촘촘한 테스트를 기반으로 에러가 없다는 것을 확정하며, 각종 성능 테스트를 통해 로직이 비효율적이지 않다는 것을 보증하는 단계이다.
✅ 최종 목적
↳ Regression Bug 를 우려한 비효율적인 중복테스트를 방지하는데 목적을 두고 있다.
🧐 이전에도 꽤 촘촘한 테스트를 진행한거로 아는데, 이거도 비효율적인거 아닌가요?
변경 가능성을 염두해두고 설계한 CRUD & Pagination 이었다. → 변경이 되었으니 다시 해야지…
그리고 이전의 테스트 방식은, 모든 팀원이 JUnit 등의 테스트에 익숙하지 않기 때문에, 수동 테스트를 진행한 것이었다. 이는 직관적인 방법이기 때문에 테스팅 러닝커브로 인한 개발 지연 이슈가 발생하지 않는다는 장점이 있지만, 중간에 테스트를 다시 진행할 때마다 Postman을 켜서 로그인을 하고 일일이 테스트를 해야한다는 문제가 있다.
즉, 기존의 테스팅은 시작단계에서의 개발지연은 줄여주는 방식이었으나, 지속적인 관점에서는 오히려 개발지연이 발생하는 구조였다.
따라서, 다음과 같이 판단을 했다.
🧐 TDD에 대한 회의적인 입장들도 많던데? 아무래도 ROI를 고려했을 때, 비용이 큰 작업일 수 있으니말야
인정한다. 너무 짜잘한 것들을 테스트하는건 오히려 유지보수 및 관리비용을 높이는 일이다.
그래서 JUnit 기반 테스트 할 때는 Service Layer에서 CRUD 테스트하고, Mocking이 아닌 실제 DB로 🧐 제대로 의도대로 동작했는지에 대한 정상/비정상 시나리오 수준으로만 점검한다. 철저히 비즈니스 로직 관점에서만 테스트하겠다는 의미다.
JUnit에서의 Pagination Test는 정렬 조건이 제대로 적용되었는지, N+1 문제가 발생하지 않는지, 실행계획은 어떤지 등을 포함한 정상/비정상 시나리오를 테스트하고, Deep Paingination에 대한 성능적인 부분에 한정하여 Postman 개별 테스트 진행한다. (데이터 응답과 응답시간을 같이 직관적으로 볼 수 있으니까)
🧐 왜 Deep Pagination은 자동화된 테스트 대상에 안들어가죠?
데이터 셋업 비용이 너무 크다. 배포 파이프라인 상 100만건 Insert가 가당키나 하겠는가…? 차라리 한번 제대로 테스트하고, 실행계획 테스트만 자동화하는게 차라리 더 효율적일 것이다.
각 도메인에 대한 Task Flow, 도메인 간 Task Flow를 상정하고 Test Automation을 진행한다.