찍어보는데 안되고... 범위는 갑자기 넓어지고... (레벨 테스트 1일차 작업 회고)

 

오늘의 레벨 테스트 작업 목표는 상품 내역 조회 페이지의 인터페이스와 해당 API 처리 백엔드 로직을 구현하는 것이었다. 작업은 아직 진행 중이고, 구현 과정에서 2가지 이슈가 있었다.

 

먼저 인수 테스트에 작성한 내용을 나타내는 작업을 Store의 동작으로 나타내려고 했다. 그 과정에서 테스트 코드를 같이 작성하려 했는데, 인수 테스트의 케이스들을 단위 테스트에서 작성하다 보니 같은 테스트 내 동일한 동작의 결과로 다른 값을 반환하게 해주는 과정이 필요하겠다는 생각이 들었다.

 

예를 들면 Store에서 ApiService에 상품 목록을 요청하는 단일한 메서드로 어떨 때는 리스트에 상품 목록이 없는 경우를, 어떨 때는 상품 목록이 3개 있는 경우를, 또 어떨 때는 상품 목록이 40개를 반환하는 경우가 필요한 경우가 생겼는데, 이를 테스트별로 서로 각기 다른 mocking을 해주는 것으로 해결할 수 있는지 시도해보았지만 잘 되지 않았다. 오전 시간 전체와 오후 1~2시까지 시간을 들였지만 잘 되지 않아 일단 다른 예외 케이스들을 주석처리를 한 뒤 하나의 테스트 케이스를 기준으로 구현을 진행하고 있다.

 

 

Mocking의 상황 별 분기가 가능한지 실험했던 흔적

 

 

두 번째 이슈는 작업 도중 구현해야 하는 범위의 확장이었다. 가장 먼저 상품 목록들을 조회하는 기능을 구현하기 위해 프론트엔드 인터페이스를 확립한 뒤, 백엔드 API 요청을 구현하는 단계로 넘어갔다. 백엔드를 구현하면서 생각을 미처 하지 못한 부분을 느끼게 되었는데, 상품 목록'들'에 대한 로직을 만들기 위해서는 '단일 상품'을 어떻게 나타낼 것인가를 구현해야 했다. 그러다보니 최초에 세웠던 상품 목록들 조회에 대한 구현에 더해 상품 상세 목록 조회의 백엔드 처리 구현을 동시에 하게 되었다. 인지해야 하는 범위가 넓어지니 구현 속도가 다소 늦어지게 되었고, 오늘도 목표 범위에 근접하기 위해서는 또다시 새벽 이슬을 보게 될 처지에 놓였다.

 

일과를 시작하면서 목표를 정할 때, 이 목표가 다른 목표의 상위 단계의 목표는 아닌지, 목표대로 작업을 진행하다가 작업의 범위가 넓어질 염려는 없는지 최소한의 고민을 한 뒤 작업 목표를 설정해야 하겠다.