Conversation
jinyoungchoi95
left a comment
jinyoungchoi95
left a comment
There was a problem hiding this comment.
안녕하세요 😄
2단계 잘 진행해주셨네요 👍 몇가지 코멘트 남겨두었으니 확인부탁드려요.
궁금하거나 고민이 되는 부분이 있으시다면 언제든 pr 코멘트 또는 dm으로 요청 부탁드립니다.
감사합니다 🙇♂️
| 먼저 id 1번의 "보내는사람" 회원이 존재한다 | ||
| 그리고 id 2번의 "받는사람" 회원이 존재한다 | ||
| 그리고 id 100번의 "테스트카테고리" 카테고리가 존재한다 | ||
| 그리고 카테고리 100번에 id 100번의 "테스트상품" 상품이 존재한다 |
There was a problem hiding this comment.
feature 파일에서 ID 직접 지정: 사용자 관점에서는 "카테고리1"을 만든다. 그리고 "카테고리1"에 물품을 넣는다가 자연스럽지만, 이렇게 하면 물품 생성 시 카테고리를 SELECT로 조회해와야 해서 ID를 직접 지정하는 방식(id 100번의 "테스트카테고리")을 사용했습니다. 이 트레이드오프에 대해 의견 주시면 감사하겠습니다.
말씀하신 것처럼 특정 카테고리 id를 가지고 생성해야한다면 이 방법을 사용하는데 크게 문제가 없을 것 같아요.
트레이드오프가 잘 이해가지 않는데 해당 방식의 어떤 문제가 발생할거라고 보시는걸까요?
시나리오의 경우 의도상 사용자의 행동흐름에 따라 feature 문서의 내용을 작성하는 것이 읽기에 자연스러운 것은 맞아요. 다만 api 서버라는 특성, 검증에는 id에 대한 특정성이 필요함이라는 이유로 온전히 개발적인 내용이 없는 자연스러운 자연어로는 남기기 힘든면이 없지 않아 있을 것 같네요 :)
There was a problem hiding this comment.
id를 지정하고 참조한다면 조금 더 실질적인 방식이지만 (클라이언트에서는 어차피 id로 전달할 것이므로)
자연어로 작성하여 이해가 편하다는 장점을 희석시킬 수 있다고 생각했었습니다!
다소의 개발적인 요소는 어쩔수 없을 것 같네요. 조언 감사합니다!
There was a problem hiding this comment.
테스트 실행 구조: 테스트 코드는 호스트 JVM에서, 앱/DB는 Docker 컨테이너에서 실행하는 구조입니다. 테스트까지 컨테이너에 넣는 방식과 비교했을 때 현재 구조가 적절한지 피드백 부탁드립니다.
테스트까지 컨테이너에 넣는 방식의 장점에 대해서 고민해보면 좋을 것 같아요. 현재는 별도로 호출해도 되는 환경이지만 다른 사람의 환경, ci의 환경 모두 다른 환경에서 테스트 호출이 실패하는 경우를 가정한다면 가능하면 모두 docker 컨테이너 안에서 실행이 될 수 있도록 구성하는 것도 좋을 것 같네요 :)
| 먼저 id 1번의 "보내는사람" 회원이 존재한다 | ||
| 그리고 id 2번의 "받는사람" 회원이 존재한다 | ||
| 그리고 id 100번의 "테스트카테고리" 카테고리가 존재한다 | ||
| 그리고 카테고리 100번에 id 100번의 "테스트상품" 상품이 존재한다 | ||
| 그리고 상품 100번에 재고 1개짜리 id 2번의 "옵션B" 옵션이 존재한다 | ||
| 만일 회원 1번이 옵션 2번 5개를 회원 2번에게 선물하면 |
There was a problem hiding this comment.
회원명("보내는사람")으로 문서를 작성하는 것이 더 자연스러운데 20라인처럼 "회원 1번이"라는 문구가 어색하다면 15라인의 jdbc 호출과 함께 보내는사람과 회원번호를 map에 캐싱해두고 사용하는 방법도 있겠네요
There was a problem hiding this comment.
"보내는사람"부분에 해당하는 회원명이 unique가 아니라 id단위로 작성하는게 더 실질적인 테스트일 것 같긴 한데,
문구가 너무 어색해서 고민이 많네요. feature의 가독성을 위해서 실제 동작 방식과는 다른 테스트문구를 작성해도 괜찮을까요?
There was a problem hiding this comment.
각 시나리오들의 정의는 어떻게 구성하였을까요? 온전히 ai가 구성한 것인지, 시나리오 도출 과정이 있는 것인지 궁금하네요 👀
There was a problem hiding this comment.
이전에 직접 작성했던 인수테스트 코드가 있어서 이를 기반으로 1차 작성을 요청한 후,
어색한 문장이나 너무 많은 책임을 가진 문장들을 개선하고 분리하는 방식으로 진행했습니다!
There was a problem hiding this comment.
한번에 전체 스택을 관리하기보다는 infra영역과 어플리케이션 영역을 분리해볼수도 있을 것 같네요.
msa 환경이나 여러 infra 환경이 있다라는 것을 가정한다면, 이후에 docker-compose.yml을 관리하기 힘들어질 수 있고 각 목적에 따라 분리했을때의 장점도 고민 포인트가 될 수 있을 것 같아요.
| systemProperty 'cucumber.glue', 'gift.acceptance.cucumber' | ||
| systemProperty 'cucumber.features', 'classpath:features' | ||
| systemProperty 'cucumber.plugin', 'pretty' | ||
| dependsOn 'dockerUp' |
There was a problem hiding this comment.
명령어 하나만 실행해도 모두 동작할 수 있도록 잘 구성해주셨네요 👍
3 participants
Summary
코드 리뷰 반영 및 오류 수정
@RequestBody어노테이션 추가 (CategoryRestController,ProductRestController)form-urlencoded→JSON body로 수정요구사항 2: Cucumber BDD 테스트
.feature파일로 카테고리/상품/선물 시나리오 작성CommonStepDefs에 배치SharedContext로 시나리오 내 Response 공유CucumberSuite를 통한 JUnit Platform 연동요구사항 3: Docker Compose 테스트 인프라
dockerBuild→dockerUp→cucumberTest→dockerDown./gradlew test(H2)와./gradlew cucumberTest(PostgreSQL Docker) 분리학습 기록
리뷰 포인트
이전 PR에서 못 여쭤본 것들
"카테고리1"을 만든다. 그리고 "카테고리1"에 물품을 넣는다가 자연스럽지만, 이렇게 하면 물품 생성 시 카테고리를 SELECT로 조회해와야 해서 ID를 직접 지정하는 방식(id 100번의 "테스트카테고리")을 사용했습니다. 이 트레이드오프에 대해 의견 주시면 감사하겠습니다.이번 PR