[BE] refactor: 인수 테스트 리팩터링

[70825]

Issue

• close [BE] 인수 테스트 리팩터링 #633

✨ 구현한 기능

• 진짜 인수 테스트 완성??
• 불편했던 코드들 개선하고, 코드도 가독성 좋게 바꾸려고 많이 고민했어요
• 코드를 확인할 때, 깃허브에서 보는 것보다 gh pr checkout 653로 보는게 더 편할 것 같습니다

📢 논의하고 싶은 내용

❗️ 큰 내용은 아래 내용이라 코드 보고 개선할 부분 있으면 알려주세요

---

0. 이제 진짜 인수테스트가 아닐까?

[진짜 인수테스트란 무엇일까요?]

제가 레벨 2에서 경험해보니 통합테스트, E2E테스트, 인수테스트는 메서드명만 다른 것처럼 보였고, 지하철 노션도 미션을 할 때 도저히 차이를 모르겠어서 리뷰어님에게 질문을 한 적이 있습니다. 리뷰어님의 답변도 관점에 따라 다르다라는 것이었어요. 이 말은 사실상 E2E랑 인수 테스트랑 코드 작성하는건 비슷하다는 이야기로 들렸습니다. (아래에 질답글 있음)

이번에 리팩터링을 하면서 다시 검색을 해봤는데, 브라운의 우아한 ATDD 영상이 있더라구요. 이걸 보니 인수테스트란 사용자 시나리오를 기반으로하는 E2E테스트이다라고 나와있었습니다.

영상 내용을 살펴보면 결국 브라운이 설명한 인수 테스트도 현재 우리 인수 테스트와 비슷한 것 같아요.
오히려 영상에 나오는 인수 테스트 코드 예시보다 우리 인수 테스트 코드가 더 가독성이 있다는 생각이 듭니다...??

그리고 우리는 API를 최대한 활용하여 만들었으니 Repository 로직이 있어도 이것도 인수테스트라는 생각이 듭니다.
결국엔 상품, 태그 데이터는 관리자가 추가를 해주는 것이지, 사용자가 추가하는게 아니니까요

지하철 노선도 미션에서 했던 질문

[질문]

[답변]

---

1. 로그인 쿠키 방식 변경

이제 원하는 멤버의 쿠키를 얻을 수 있어요
이전까지 무조건 1번 유저 쿠키만 받을 수 있는데, 이제 숫자 넣어주면 특정 유저의 쿠키를 얻을 수 있습니다
그리고 로그인 쿠키를 얻는 로직 자체가 새로운 멤버를 생성할 수 있으므로 정말 필요한 곳 아니면 MemberRepository가 필요 없어졌어요

1번 유저를 가입하고, 쿠키를 얻음

로그인_쿠키를_얻는다(1L)

혹시나 까먹어도 IDE에서 쉽게 파악할 수 있게 파라미터를 final Long memberId로 했습니다

---

2. RestAssured 요청 메서드 파라미터 순서 변경

인수 테스트를 작성할 때, 어떻게 하면 코드를 더 쉽게 읽을 수 있을까 고민을 많이 했는데, 육하원칙 순서랑 비슷하게 설정하면 더 좋을 것 같더라구요
그리고 코드가 final var 변수명으로 시작하는게 아니라, 메서드가 시작하도록해서 어떤 역할을 하는지 바로 파악할 수 있도록 하면 좋아보였어요

[이전 코드]
final var productId = 단일_상품_저장(상품_삼각김밥_가격1000원_평점3점_생성(category));

[개선 코드]
단일_상품_저장(상품_삼각김밥_가격1000원_평점3점_생성(category));

예시 1) 리뷰_작성_요청(로그인_쿠키_획득, 상품_번호, 파라미터들...)

• 누가? - 로그인_쿠키_획득 - 1번 유저가
• 어디서? - 상품_번호 - 1번 상품에
• 무엇을? - 리뷰_작성_요청 - 리뷰 작성을 누르다
• 어떻게? - 파라미터들 - 2점과 맛있어요 태그를 선택한 상태에서

예시 2) 레시피_좋아요_요청(로그인_쿠키_획득, 상품_번호, 파라미터)

• 누가? - 로그인_쿠키_획득 - 2번 유저가
• 어디서? - 상품_번호 - 1번레시피에
• 무엇을? - 레시피_좋아요_요청 - 좋아요를 누르다
• 어떻게? - 파라미터들 - 좋아요가 true인 상태에서

---

3. 최대한 메서드 및 변수명 삭제 및 통일성 적용

• AcceptanceTest에 API가 없어서 사용해야만 하는 단일_@@_저장를 제외하고는 모두 삭제했습니다.
• 원래 처음엔 actual, expected 이 변수는 무조건 필요하다고 생각을 했는데, 간단한건 굳이 expected로 저장하지 않고, 바로 then에서 적으면 되지 않을까?라는 생각이 많이 들었어요.
• 이외에도 정말 변수명을 저장해서 사용하는 것이 아니라면 되도록 메서드가 접두사가 될 수 있도록 했습니다.
• 그리고 여러명이_리뷰_좋아요_요청, 여러명이_레시피_좋아요_요청 메서드를 사용하는 곳에서 혼자 좋아요를 누르는 경우도 있는데, 이건 통일성을 위해 여러명이_레시피_좋아요_요청으로 통일성 있게 바꿨습니다.

🎸 기타

문제점

• 상세 정보는 createdAt을 제외한 모든 정보를 테스트 해보면 좋다고 생각합니다. 그런데 레시피 작성 요청이 MultiPartFile로 데이터를 보내면 한글 인식이 안됩니다.
  리뷰 작성의 경우에는 잘 돌아가는데, 이건 왜 안되는지 모르겠어서 확인해보니 차이가 이미지가 MultiPartFile이냐, List.of(MultiPartFile)이냐로 다른 것 같아요

⏰ 일정

• 추정 시간 : 6
• 걸린 시간 : 18

[github-actions]

Unit Test Results

224 tests  +1   224 ✔️ +1   17s ⏱️ +2s
112 suites ±0       0 💤 ±0 
112 files   ±0       0 ❌ ±0 

Results for commit 00bd399. ± Comparison against base commit 14558cb.

♻️ This comment has been updated with latest results.

[wugawuga]

대규모 리팩터링 너무 수고하셨습니당

[70825]

레시피 작성 요청 List.of(MultiPartFile)이 문자가 인식이 안되는게 아니라 한글 인식이 안되네요 (영어는 잘 나옴)

[hanueleee]

진짜 레전드 리팩토링..
로건 수고하셨습니다 😆

[hanueleee]

Suggested change

	final var response = 로그아웃_요청(로그인_쿠키_획득(1L));
	final var 사용자 = 로그인_쿠키_획득(1L);
	final var 응답 = 로그아웃_요청(사용자);

로그인을 해야 로그아웃을 할 수 있으니
이런식으로 흐름을 한번 끊어주는건 어떨까요?

[wugawuga]

리뷰 반영 후 코드가 확실히 가독성이 높아져서 너무 좋습니다 수고하셨어요 ㅎㅎ

[Go-Jaecheol]

코드 리뷰하는데도 양이 엄청 많은데, 이걸 직접 리팩토링한 로건.. 폼 미쳤다.. 👍👍
고생하셨습니다~~