밀린다

 

게시글 상세 정보 조회를 위한 로직을 이틀에 걸쳐 구현을 진행 중이다. 특정 게시글이 포함하고 있는 게시물 내용, 경기 정보, 참가자 목록 정보를 백엔드 서버로부터 가져와 사용자, 신청자, 신청자가 아닌 사용자에 따라 UI를 구분해 출력되도록 하는 것이 작업의 최종 목표이다.

 

월요일에 작업 목록을 새로 작성할 때, 작업이 너무 클 것 같아 작업 단위를 나눴었다. 먼저 게시글을 구성하는 각각의 리소스인 '게시글', '경기', '참가자'에 대한 내용을 일단 가져와 출력하기만 하게 구현한 뒤, DTO에 추가적으로 같이 전달하게 하는 사용자 식별을 위한 값을 이용해 컴포넌트가 출력할 내용을 구분하는 내용을 구현할 계획이었다.

 

게시글 상세 정보 조회의 약식 내용이다. 형광색으로 표시한 부분을 먼저 구현하고 있다. 빨간색으로 표시한 내용은 '신청'이라는 모델이 추가되어야 하기 때문에 상세 정보 조회와는 다른 별도의 기능으로 분리했다.

 

남은 일정과 작업 목록을 고려한다면 오늘이 끝날 때쯤에는 적어도 리소스를 출력하는 로직은 구현을 마쳤어야 했는데, 하루가 거의 끝난 지금 구현 정도는 일차적으로 내용만 가져와 출력하도록 하는 동작에서 백엔드의 요청 처리 과정을 50% 가량 구현한 상태이다.

 

작업이 지연된 원인을 생각해보았다.

 

 

이번에도 새로운 작업의 인터셉트

게시글 상세 조회 작업 UI 컴포넌트 작업을 진행해놓은 뒤, 소스코드를 작성은 했지만 통과시키지는 못하고 있던 인수 테스트를 통과시키는 작업을 마저 진행하려 했다. 문제는 사용자를 구분하기 위해 Access Token을 브라우저에서 임의로 직접 변경시키는 방식으로는 인수 테스트에서 명시적으로 사용자를 구분해줄 방법이 없었다.

 

인수 테스트에 스크립트를 추가시켜서 Access Token을 부여하는 시도를 해 보았지만 실패했고, 실제 사용자가 사용하는 방식이 아닌 해킹에 가까운 방식을 사용하는 것은 인수 테스트의 의의에 맞지 않음을 확인하고 하루에 걸쳐 User Id를 입력받아 백엔드 서버로부터 Access Token으로 반환받는 방식의 임시 로그인 기능을 구현했다.

 

이마저도 아이디나 비밀번호를 입력하는 실제 사용 방식과는 거리가 있기 때문에 아이디와 비밀번호를 이용하는 방식으로 리팩터링할 계획이다.

 

인수 테스트를 통과시키는 것이 진정한 의미의 기능의 완성이라고 볼 수 있기 때문에, 앞선 기능을 모두 완성시킨 뒤 다음 작업을 진행한다는 의미를 가질 수 있게 되었다. 다만 추가된 임시 로그인 작업으로 인해 작업이 하루 가량 지연되었기 때문에 원래 계획했던 작업 일정이 늦춰지게 되었다.

 

 

단위 테스트를 너무 세밀하게 작성하나?

사실 1차적으로 구현하는 상세 정보 조회는 백엔드 서버에서 각각의 리소스를 따로따로 가져와 그대로 UI에 전달하기만 하면 되기 때문에 먼저 했던 리스트 조회를 구현했던 수준에서 크게 벗어나지 않는다. 프론트엔드 구조 자체는 UI, 페이지, Store, API 호출 모두 이전에 했었던 게시글 목록 조회와 비슷하고, Store는 fetchPost가 만들어지면 fetchGame, fetchMembers는 데이터만 다르고 복붙에 가깝다. 설계 과정도 문서를 쓰고 작업 계획을 세우면서 충분히 했다고 생각했는데, 생각보다 코드를 치는 효율이 나오지 않았다.

 

단위 테스트를 너무 세밀하게 작성하는 것이 문제일까. 그 시점에서 생각할 수 있는 모든 예외처리를 잡고 가고 있다고 생각하고 있었다. 게시글 목록 조회를 구현할 때도 테스트 코드를 통해 정상적인 동작이나, 처리 과정에서 발생할 수 있는 예외사항은 (예를 들면 RuntimeException) 모두 잡으면서 가고 있다고 생각했었다. 하지만 월요일에 스프린트 결과 분석을 하면서 생각하지 못했던 예외사항을 발견하기도 했었다.

 

지금 하고 있는 작업은 한 번에 기능을 완성시키는 것이 아닌, 단계를 나눠서 일부분을 완성한 뒤에 나머지 부분을 붙여 마저 완성하는 방식을 계획하고 있는 상태인데, 그러면 일단 작업 속도가 안 나는 고통을 덜기 위해 정상적인 케이스만 테스트를 진행하면서 기능을 완성하고, 하나의 흐름이 완성되었을 때 예외처리에 대한 검증을 보완하는 방식이 나은 선택일까. 잘 모르겠다.

 

 

 

스프린트 4주차 목요일까지의 작업 내역

- 게시글 상세 정보 UI 컴포넌트

https://github.com/hsjkdss228/smash-frontend/pull/19

 

- 임시 로그인

https://github.com/hsjkdss228/smash-frontend/pull/20

https://github.com/hsjkdss228/smash-backend/pull/14

 

- 게시글 목록 조회, 운동 참가 신청, 운동 참가 취소 인수 테스트

https://github.com/hsjkdss228/smash-frontend/pull/21

 

- 게시글 상세 정보 페이지 컴포넌트, 상태 관리, API 요청

https://github.com/hsjkdss228/smash-frontend/pull/22