문서와 테스트는 어느 정도로 심도있게 작성하는 게 맞는 걸까...? (레벨 테스트 4일차 작업 회고)

 

오늘 구현하려 했던 목표는?

• 예외처리를 제외한 주문, 주문 내역 로직 구현 (계정 개념을 아직 정의되지 않았으므로 잔액 개념은 우선은 임시로 별도의 Store에서 관리하도록 한 뒤, 추후 계정 개념을 만들 때 이관)
  
  

어제 트레이너님께서 알려주셨던 Mocking 재할당 관련 이슈를 자정을 넘기고 다시 수정해서 적용해보려 했는데 적용되지 않는 이슈가 계속 발생했다. 더 이상 매달렸다가는 남은 기간 동안의 컨디션에도 악영향을 미칠 것 같아 잠시 롤백시킨 뒤 새로 구현해야 할 부분들을 우선 구현해보기로 했다. (해당 문제는 오늘 프론트엔드에서 새로 구현한 단위 테스트를 작성하던 중 문제를 해결할 수 있는 경우를 찾아 똑같은 방법으로 적용해볼 수 있을지 시도해보려 한다.)

 

작업을 하면서 프론트엔드의 동작이나 백엔드로의 요청, 응답과 관련된 인터페이스를 정의할 때 문서에 정리하면서 작업을 진행하고 있다. 정의의 기준은 Figma에 제시된 내용 또는 인수 테스트를 작성할 때 작성했었던 사례들을 참고하고 있다.

 

오늘 오후 쯤에 느꼈던 생각인데, 4시 쯤에 OrderStore의 단위 테스트를 작성하면서 '내가 테스트나 문서 작성을 너무 빡빡하게 하고 있나?' 싶었다. 그때쯤이 되어서야 상품 주문의 프론트엔드 단에서의 인터페이스 정의가 끝났기 때문이었다. (사실은 끝난 게 아닐 수도 있다. 계정 개념이 추가되고 내가 인지하지 못했던 예외사항이 만약 나타난다면?)

 

테스트 코드를 작성하는 과정에서 모든 예외처리 케이스들을 테스트의 대상으로 작성하려고 했다. 이때 어떤 테스트들은 작성할 때 실제로 테스트하고 싶은 동작 그 자체보다 Given에 해당하는 사전 설정이 훨씬 비대해지는 경우가 나타났다. 로직을 최적으로 분리하는 능력이 아직 부족하다 보니 비슷한 코드가 반복적으로 나타났다.

 

그리고 테스트를 작성하는 과정에서 나타나는 로직에 추가되어야 하는 부분들을 문서에 반영하면서 작업하다 보니 문서에서 해당 부분을 찾는 데 드는 시간이 추가로 들면서 구현에 쓰는 시간을 잡아먹고 있다는 느낌이 든다.

 

테스트 코드는 정말로 모든 예외 케이스들을 다룰 수 있어야 할까? 아니면 핵심적으로 잡아야 하는 부분에만 집중하면 되는 것일까? 나도 구현에 속도를 내는 게 좋을지... 레벨 테스트를 진행하는 작업의 방향성에 고민이 들고 있다.