테스트 작성이 너무 어려워요...

Question

단일 함수에 대한 유닛테스트는 비교적 간단하지만, CRUD API 함수 테스트는 어떻게 접근하는 것이 좋을지 고민됩니다.예시 상황댓글 삭제 기능 테스트comment 테이블이 post, user 테이블과 연관관계를 가짐현재 생각해본 방법들과 각각의 장단점은 다음과 같습니다:1. DB 모킹 방식장점: 순수 코드 로직만 검증 가능, 테스트가 빠르고 간단단점: 실제 DB와의 상호작용이나 쿼리 동작 검증 불가능2. DB 모킹 없이 전체 플로우 테스트장점: 실제 DB 동작 검증 가능단점: 사용자 생성 → 로그인 → 게시글 작성 → 댓글 작성 → 삭제 → 검증까지 테스트 코드가 매우 길어짐추가 문제: 테이블 컬럼이 많을 경우 더욱 복잡해짐 (예를들어 post의 컬럼이 30개이면 row생성을 위해 30개의 컬럼을 다 채워줘야함)3. Seed 데이터 활용 방식장점: 미리 준비된 데이터로 테스트 시작점을 단순화단점: seed 데이터 유지보수 필요, seed 변경 시 관련 테스트들 모두 영향받음질문실무에서는 주로 어떤 방식을 사용하시나요?테스트 작성이 너무 복잡하게 느껴지는데, 제가 접근을 잘못하고 있는 걸까요?조언 부탁드립니다!

코딩하는 두루미 · Answer

저도 잘 몰라서 GPT에 함 넣어봤음요좋은 고민이에요. 결론부터 말하면 “한 가지 방식만” 쓰지 않습니다. 현실적인 전략은 테스트 피라미드에 맞춰 레이어(단위/슬라이스/통합/E2E)를 섞고, 테스트 데이터 생성 비용을 줄이는 도구화가 핵심이에요. 아래처럼 접근해 보세요.1) 어떤 테스트를 어디서 할까? (전략)단위(Unit): 도메인 로직/서비스 로직을 리포지토리·외부의존성 모킹으로 빠르게 검증→ 예: “댓글 삭제 시 권한 체크, 소프트 삭제 여부” 같은 순수 규칙.슬라이스(Slice): 프레임워크별 부분 통합Spring이라면 @DataJpaTest로 JPA 쿼리/엔티티 매핑 검증 (실DB 대체: H2 금지 권장, 가능하면 Testcontainers로 실제 엔진과 동일하게)@WebMvcTest로 컨트롤러 필터·바인딩·밸리데이션만 빠르게 확인.통합(Integration): 애플리케이션을 거의 실제처럼 올리고 DB는 Testcontainers(MariaDB) 사용→ 실제 트랜잭션/쿼리/스키마 동작 확인. 여기서 CRUD API의 핵심 흐름(권한, 삭제 후 조회 결과)을 검증.E2E(소수): 진짜 사용자 플로우(회원가입로그인글/댓글~삭제)를 아주 적은 시나리오만 커버→ 행복 경로 + 치명적 엣지(권한 없음, 이미 삭제됨 등) 정도로 개수는 최소화.실무에서는 위 네 층을 섞고, E2E를 비대하게 만들지 않는 것이 일반적입니다.2) “DB 모킹 vs 실제 DB”는 답이 아니라 범위모킹은 규칙/분기 검증에,실제 DB(Testcontainers)는 매핑/쿼리/트랜잭션/락/인덱스 영향 같은 현실성 검증에 씁니다.둘 다 필요하지만 각자의 자리가 달라요.3) 데이터가 많아 복잡해진다? → “테스트 데이터 빌더/팩토리”로 해결컬럼이 30개인 post 때문에 테스트가 길어지는 건 도구화 부족 문제예요.다음 3가지를 준비하면 급격히 편해집니다.(1) Test Data Builder / Factory (기본값 + 선택적 override)모든 필드에 합리적 기본값을 넣어두고, 바꾸고 싶은 것만 지정:public class PostBuilder { private String title = "제목"; private String content = "본문"; private boolean deleted = false; // ... 27개 기본값 private User author = new UserBuilder().build(); public PostBuilder title(String v){ this.title = v; return this; } public Post build(){ return new Post(title, content, deleted, /* ... */, author); } } 테스트에서는:Post post = new PostBuilder().title("삭제 테스트").build(); → 30개를 다 안 써도 됩니다.(2) 연관 팩토리 자동화CommentFactory.create()가 내부에서 User, Post를 자동 생성/저장하도록:public class CommentFactory { @Autowired UserRepository users; @Autowired PostRepository posts; @Autowired CommentRepository comments; public Comment create(Map overrides){ User u = (User) overrides.getOrDefault("user", users.save(new UserBuilder().build())); Post p = (Post) overrides.getOrDefault("post", posts.save(new PostBuilder().build())); Comment c = new CommentBuilder().user(u).post(p).build(); return comments.save(c); } } → “댓글 하나 필요”가 “연관까지 알아서”로 단축됩니다.(3) 랜덤/자동 채움 도구Java라면 Instancio, EasyRandom 같은 라이브러리로 필요한 필드 자동 채움 + 일부 필드만 override.(JS면 test factory + faker, Python이면 factory_boy 같은 느낌)4) Seed 데이터? 가능하면 “시나리오 단위 팩토리”로 대체전역 seed는 유지보수가 어려워 의존 꼬임이 생깁니다.대신 테스트 시작 시 필요한 만큼만 팩토리/빌더로 생성하세요.정말 공통이 필요한 경우에도 “작은 시나리오 시드(예: basicMembers.sql)”로 나누고, 테스트마다 @Sql로 명시적으로 불러옵니다. (숨겨진 글로벌 시드는 지양)5) 인증/인가는 “우회 포인트”를 만든다댓글 삭제 API가 “로그인 → 토큰 발급 → 헤더 세팅”까지 다 요구하면 테스트가 길어집니다.실무에서는 통합 테스트에서:JWT 발급기를 테스트용으로 주입해 바로 유효 토큰 생성또는 시큐리티 레이어만 모킹해서 컨트롤러 단에서 @WithMockUser 비슷한 방법으로 권한만 세팅→ “인증 자체”는 몇 개의 별도 테스트로 빼고, CRUD 테스트는 핵심 행위에 집중.6) Spring Boot 3.2 + MariaDB의 권장 템플릿(사용자 환경 메모에 Spring Boot 3.2, MariaDB가 있어 이 조합 기준으로 예시 드려요.)통합 테스트 예시(댓글 삭제)@SpringBootTest @AutoConfigureMockMvc @Testcontainers class CommentDeleteApiTest { @Container static MariaDBContainer db = new MariaDBContainer<>("mariadb:10.11"); @DynamicPropertySource static void props(DynamicPropertyRegistry r){ r.add("spring.datasource.url", db::getJdbcUrl); r.add("spring.datasource.username", db::getUsername); r.add("spring.datasource.password", db::getPassword); } @Autowired MockMvc mvc; @Autowired CommentFactory comments; @Autowired TokenHelper tokenHelper; // 테스트용 토큰 발급기 @Test void 내_댓글을_삭제하면_조회시_안나와야_한다() throws Exception { var comment = comments.create(Map.of()); // post/user 포함 자동 생성 var token = tokenHelper.issueFor(comment.getUser().getId()); mvc.perform(delete("/api/comments/{id}", comment.getId()) .header(HttpHeaders.AUTHORIZATION, "Bearer " + token)) .andExpect(status().isNoContent()); mvc.perform(get("/api/posts/{id}/comments", comment.getPost().getId())) .andExpect(status().isOk()) .andExpect(jsonPath("$[?(@.id == %d)]", comment.getId()).doesNotExist()); } } 포인트:Testcontainers로 실제 MariaDB에 가깝게.Factory로 연관 데이터 자동 생성.토큰 헬퍼로 인증 간소화.삭제 정책(하드/소프트)은 조회 API 결과로 검증.7) 데이터 격리/정리각 테스트는 트랜잭션 롤백 또는 Testcontainers DB 재사용 + TRUNCATE 전략 중 하나를 사용.Flyway/Liquibase 마이그레이션을 테스트에도 그대로 적용해 스키마 일치 보장.8) 무엇을 어디까지 테스트할까? (범위 가이드)단위: 규칙/분기(권한X → 403, 이미 삭제됨 → idempotent 처리 등) 최대한 커버슬라이스(JPA): 쿼리 성능/정확성(조인, 페치 전략, 삭제 플래그 조건)통합(API): 대표 시나리오 3~5개(본인 삭제, 타인 삭제 시 403, 없는 ID 404, 이미 삭제 204, 관리자가 삭제)E2E: 정말 필요한 플로우 12개만 (전체 가입로그인 포함)즉, CRUD 전 과정을 항상 한 테스트에 우겨넣지 않습니다.“무엇을 여기서 증명할 것인가”를 정하고 테스트를 분해하세요.9) 체크리스트 (실무 요약)Factory/Builder로 데이터 생성 비용 제거인증/인가는 테스트용 우회 제공*Testcontainers(MariaDB)*로 실제성 확보전역 seed 지양, 시나리오 단위로 명시적 로딩슬라이스 테스트로 빠른 피드백, 통합 테스트는 적지만 굵게각 테스트는 하나의 주장만 명확히 검증질문에 대한 짧은 답실무에서는 1,2,3을 혼합합니다. 모킹은 규칙 검증, Testcontainers로 DB 통합, seed는 최소화/시나리오화.복잡하게 느껴진다면 접근을 잘못한 게 아니라 도구화(Factory/Builder)와 범위 분리가 부족했던 겁니다. 위 구조로 재편하면 테스트가 짧고 단단해집니다.

스프링잡부 · Answer

Cursor한테 테스트코드 짜달라고 하면 기깔나게 짜줍니다

하루히즘 · Answer

어차피 테스트할 때는 스테이지나 운영 DB 못 붙으니까 3번으로 했었는데 생각보다 상당히 귀찮아서 다들 잘 안하더라구요 ㅋㅋㅋ 의존성 다 모킹하고 1번으로 그나마 비즈니스 로직같은거 검증하는 식으로 저희는 하구잇어요

테스트 작성이 너무 어려워요...

3개의 답변

기술 목록