<aside> 💡 주문 API가 호출하는 주문 생성 함수는 복잡한 로직을 가지고 있었습니다. 돌아가기는 하는데 리팩토링하기에는 꺼림직한 상태였기에, 일단 테스트 코드를 짜보고자 했습니다.

만만치 않았습니다. 주문 API 테스트 코드를 작성하면서 여러가지 고민들이 생겨났습니다. 이러한 고민들 때문에 테스트 코드를 작성하는데 더 많은 시간과 비용을 사용하고 있었습니다.

이런 고민과 불편함은 저희의 발걸음을 다시 리팩토링으로 향하게 했습니다. 리팩토링하기 위해 테스트 코드를 짜고자 했지만, 테스트 코드를 쉽게 짜고자 다시 리팩토링하는 방향으로 돌아간 것이었습니다.

이 글에서는 저희 팀에서 테스트 코드를 작성하는 방법 보다는, 테스트 코드를 작성하며 어떤 노동을 했고, 어떤 고민을 했고, 또 어떤 해결책을 떠올렸는지에 대해 이야기합니다.

</aside>

1. 노동의 시작

이거.. 고쳐야겠다.

FE쪽 개발 페이스를 맞추기 위해 허겁지겁 API를 짜다보니 개선의 여지들이 많이 남아있는 코드들이 쌓이게 됐습니다.

그 중 주문 API에 의해 호출되는 service 레이어의 주문 생성 함수가 가장 문제였습니다.

// 요런 느낌의 함수
async create(userId, createOrderDto: CreateOrderDto) {
    const { menus, cafeId } = createOrderDto;

    // 주문한 메뉴들에 대한 정보(가능한 옵션, 가격 등등)를 가져오는 부분

    // 가져온 정보를 쓰기 좋게 가공하는 과정
    
    // 모든 메뉴가 유효한 메뉴였는지 확인하는 과정
		// (유효하지 않은걸 db에 넣으면 알아서 걸러지기는 하지만, 애초에 아래
	  //  유효성들을 검사할 때 메뉴가 없으면 어차피 진행이 안된다.)

    // 각 메뉴마다 옵션이 모두 유효한 옵션들인지 확인하는 과정
		// 사이즈, 필수 옵션, 선택 옵션 등등..
    
    // 가격 비교

    // 주문 저장을 위한 과정
    await this.orderRepository.save(...);
    return;
  }

저희 서비스에서 가장 핵심적인 부분이다보니 더 철저하게 유효성 검증을 할 필요가 있었고, 그렇다보니 조금 보기 힘든 코드가 나왔습니다.

실제로 처음 코드를 구현했을 때 실수를 해, 유효성 검증을 추가하기 위해 코드를 조금 고쳐야했고, 애초에 코드를 짜놓은 저희도 다시 볼 때 꽤 헷갈려 고생했었습니다.

리팩토링은 필수였습니다.

일단 정상적으로 돌아가는 함수이다보니 리팩토링 전에 테스트 코드 작성부터 시작했습니다. 잘 못 건드렸다가 또 삽질하는건 너무 싫었거든요 :’)

테스트 코드 작성 시작

막상 짜려고 하니 어떻게 짜야할지 감이 안잡히더라구요. 일단 해당 함수가 현재 수행하는 동작만큼은 제대로 수행하도록 강제하고자 하는게 목표였으니, 이 친구가 수행해야할 동작들에 대해 생각해봤습니다.

주문 생성 함수는