Conversation
GiftRestController와 동일한 JSON 바인딩 패턴으로 통일한다. DTO에 setter가 없어 form param 바인딩이 불가능했던 문제를 해결한다.
조회만 수행하면서 "생성하면 조회된다"로 표현되던 테스트를 조회 테스트와 생성 테스트로 분리한다. @SQL을 메서드 레벨로 이동하여 테스트별 데이터를 독립적으로 관리한다.
테스트가 검증하는 행위를 하나로 식별하고, @DisplayName이 실제 수행하는 행위만 서술하도록 가이드를 추가한다.
생성 테스트에서 POST 응답 본문을 검증하여 생성 결과를 직접 확인한다.
ErrorCode interface, domain-specific enums (Common/Gift/Product), BusinessException, ErrorResponse DTO, and GlobalExceptionHandler. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Swap orElseThrow()/IllegalStateException for domain-specific BusinessException in services, Option model, and FakeGiftDelivery. Update test expectations to match new HTTP status codes (400/404). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Cover missing header (400), non-numeric value (400), and non-existent member (404) scenarios with response body verification. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Make BusinessException abstract, add CommonException, GiftException, ProductException. Each domain exception accepts its own ErrorCode enum. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add HttpMessageNotReadableException test case. Remove Exception fallback handler and INTERNAL_SERVER_ERROR enum with no usage. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Verify response body code in createProductWithInvalidCategory, giftFailsWhenOptionNotFound, and giftFailsWhenInsufficientStock to ensure failures are caused by the expected reason. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- setup-cucumber: one-time Cucumber BDD infrastructure setup - write-cucumber-scenario: repeatable BDD scenario writing guide - setup-docker-postgres: PostgreSQL + Docker Compose integration - dockerize-app: application containerization with multi-stage build Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
JUnit 5 기반 인수 테스트를 Cucumber BDD Gherkin 한글 시나리오로 전환. ScenarioScope 기반 ScenarioContext로 시나리오 간 상태 격리. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
spring-boot-docker-compose를 사용하여 테스트 시 PostgreSQL 자동 시작/종료. 개발 환경은 H2 유지, cucumberTest task 추가. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
App과 PostgreSQL을 모두 Docker Compose로 관리하여 프로덕션과 동일한 환경에서 E2E 테스트를 수행할 수 있도록 변경한다. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
vsh123
left a comment
There was a problem hiding this comment.
안녕하세요!
이번미션 구현 잘해주셨네요 :)
몇가지 코멘트를 남겼으니 확인부탁드리겠습니다!
| - 요구사항 2(PostgreSQL + Docker Compose)가 완료된 상태여야 한다 | ||
| - docker-compose.yml에 PostgreSQL 서비스가 구성되어 있어야 한다 | ||
|
|
||
| ## 1단계: .dockerignore 작성 |
There was a problem hiding this comment.
Docker 컨테이너로 실행하여 프로덕션과 동일한 환경에서 End-to-End 테스트를 수행
해당 skill의 목적은 테스트 수행인가요? 아니면 Dockerfile 작성 및 수행일까요??
claude code skill을 잘 인식하게 하기위해 description을 수정해주면 좋을 것 같아요!
There was a problem hiding this comment.
이 스킬의 핵심 목적은 Dockerfile 작성 및 Docker Compose를 통한 애플리케이션 컨테이너화였습니다!
현재는 테스트를 수행한다는 의미가 내포되어있어 혼란이 있을 것 같습니다. 이 부분 수정하도록 하겠습니다!
| public void give(final GiveGiftRequest request, final Long memberId) { | ||
| final Option option = optionRepository.findById(request.getOptionId()).orElseThrow(); | ||
| memberRepository.findById(memberId) | ||
| .orElseThrow(() -> new CommonException(CommonErrorCode.MEMBER_NOT_FOUND)); |
| } | ||
|
|
||
| tasks.named('test') { | ||
| useJUnitPlatform() |
There was a problem hiding this comment.
cucuberTest와 반대로 그냥 test에서는 exclude '**/RunCucumberTest*' 가 필요하지 않을까요?? 안그러면 docker없이 테스트가 실패할 것 같네요!
| classpath = sourceSets.test.runtimeClasspath | ||
| } | ||
|
|
||
| tasks.register('dockerBuild', Exec) { |
There was a problem hiding this comment.
dependsOn/finalizedBy설정에 대해 알아보고 적용해보면 어떨까요?
| import org.springframework.http.HttpStatus; | ||
|
|
||
| public enum GiftErrorCode implements ErrorCode { | ||
| OPTION_NOT_FOUND("OPTION_NOT_FOUND", "옵션을 찾을 수 없습니다.", HttpStatus.NOT_FOUND), |
There was a problem hiding this comment.
이에 따라 기존 GiftAcceptanceTest가 실패할 것 같은데 확인한번 부탁드립니다!
| runtimeOnly 'com.h2database:h2' | ||
| runtimeOnly 'org.postgresql:postgresql' | ||
| testImplementation 'org.springframework.boot:spring-boot-starter-test' | ||
| testImplementation 'org.springframework.boot:spring-boot-docker-compose' |
| TRUNCATE TABLE category; | ||
| TRUNCATE TABLE member; | ||
| SET REFERENTIAL_INTEGRITY TRUE; | ||
| TRUNCATE TABLE wish, option, product, category, member RESTART IDENTITY CASCADE; |
There was a problem hiding this comment.
신규 엔티티가 추가될때마다 해당 파일을 수정해줘야하는데요.
신규 엔티티(테이블)이 추가되더라도 자동으로 cleanUp할 수 있는 구조를 고민해보면 어떨까요?
아래의 두 가지 작업을 진행했습니다.
1번의 피드백 반영 중, CustomException을 만들어 진행해보았는데 그 과정에서 한 가지 궁금점이 생겼습니다.
제일 상위에 ErrorCode를 인터페이스로 만들고 get 메서드를 구현해놓은 뒤, 각 도메인마다 ErrorCode를 enum으로 구현체를 생성하여 변수들을 강제할 수 있지 않을까 하는 생각으로 해당 구조를 만들었습니다. 이 부분이 실무적인 측면에선 어떨지 궁금합니다.
step-2에서는 skill을 분리하여 최대한 한 번에 많은 작업을 할 수 있도록 해놓았는데, 작업 단위를 잘게 쪼개서 진행한다면 어떤 결과가 나왔을까에 대한 생각도 있습니다. 다음 단계에서는 작은 단위로 한 번 작업해보고자 하는데, 이 부분에서 조언 부탁드립니다!!
신경쓰고 있는 부분
클로드가 제가 원하지 않는 동작을 할 때마다 skill 및 CLAUDE.md를 추가/변경 및 정제하고 있습니다.