이 글에선 저번 글에서 "메뉴 옵션" 파트를 TDD로 진행하면서 개선할 부분을 어떻게 개선했는지를 다루겠습니다.
이번에 개발할 도메인은 "결제 내역", "메뉴 카테고리"입니다.
기존의 테스트 코드를 모두 작성한 후 비즈니스 로직을 작성한 부분이 가장 크게 개선할 점이었습니다.
따라서 아래의 순서를 따랐습니다.
- 테스트 목록 정리
- 실패하는 단위 테스트 작성
- 실패 테스트를 통과하는 비즈니스 로직 작성
- 2 ~ 3 단계를 반복하여 실패 테스트 코드 모두 작성
- 성공하는 단위 테스트 작성
- 성공 테스트 코드를 통과하는 비즈니스 로직 작성
위에 흐름을 따랐으며 Repository -> Service -> Controller 순으로 개발하였습니다.
개선된 TDD
Repository
Repository 테스트의 목적은 "올바른 값을 반환하는가" 였기에 실패 테스트는 굳이 적지 않고, "참조를 통한 조회 성공" 테스트만 진행하였습니다.
Repository를 테스트하면서 가장 애를 먹었던 부분은 @DataJpaTest로 테스트 시 table not found 에러가 발생하는 거였습니다.
@SpringBootTest 어노테이션을 사용하면 테스트 코드가 정상 작동하였고, 두 어노테이션의 차이를 검색하다가 다음과 같은 @DataJpaTest 어노테이션의 특징을 알게 되었습니다.
- @DataJpaTest어노테이션으로 JPA테스트를 수행하면 application.yml 파일에 정의된 데이터베이스 설정을 사용하지 못합니다.
- 원인은 @DataJpaTest 어노테이션과 함께 사용되는 @AutoConfigureTestDatabase 애너테이션 때문입니다.
- @AutoConfigureTestDatabase 어노테이션 replace 속성의 기본 값이 ANY이므로 내장 데이터베이스 객체를 생성하는 로직이 별도로 수행됩니다.
결론적으로, Application.yml에서 설정한 DB를 사용하지 못하고, 임베디드 DB를 사용한다는 것이었습니다. 이를 해결하기 위해 @AutoConfigureTestDatabase 애너테이션의 replace 속성을 NONE으로 오버라이딩하면 됩니다.
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
(pr 날리고 알게 된 해결 방법이어서, SpringBootTest 어노테이션을 사용했습니다.)
Service
1. 테스트 목록 정리
2. 실패하는 단위 테스트 작성
3. 실패 테스트를 통과하는 비즈니스 로직 작성
여기서 키 포인트는 비즈니스 로직 전체를 작성하는 것이 아닌 테스트 코드가 통과할 최소의 코드를 작성하는 것이다!
(빠르게 코드를 작성하고 피드백을 통해 코드를 수정하기 위해)
2 ~ 3을 반복하다 보면 실패에 대한 테스트 코드와 비즈니스 로직을 모두 작성하게 된다.
5. 성공하는 단위 테스트 작성
성공 테스트를 작성하면서 신경 썼던 부분은 회원, 매니저, 오너마다 권한이 달랐기 때문에 이를 테스트하는 것이었습니다.
권한이 있는 Relation을 authorities 메서드로 주입해 주고, @MethodSource 어노테이션을 이용해 주입받아 테스트하였습니다.
6. 성공 테스트 코드를 통과하는 비즈니스 로직 작성
최종적으로, 테스트가 성공하는 비즈니스 로직을 작성하면 됩니다.
Test
1. 테스트 목록 정리
2. 실패하는 단위 테스트 작성
3. 실패 테스트를 통과하는 비즈니스 로직 작성
2 ~ 3 단계를 반복하여 실패 테스트 코드 모두 작성
5. 성공하는 단위 테스트 작성
6 성공 테스트 코드를 통과하는 비즈니스 로직 작성
이로써, "메뉴 카테고리" 도메인에 대한 Repository, Service, Controller 테스트 코드와 비즈니스 로직을 모두 작성하였습니다.
TDD를 하면서 느낀 점
개발 속도: 초반 기능 개발은 느릴 수밖에 없다고 생각합니다. 하지만, 테스트 코드를 작성하게 되면 자연스럽게 테스트에 용이한 구조로 설계하게 되기 때문에 추후 구조를 리팩토링 할 때 드는 비용에 비하면 효율적이라고 생각합니다.
테스트 코드 작성: 테스트 코드를 작성하게 됩니다. 부끄럽지만 개인적으로 테스트 코드를 작성하지 않는 이유는 "이미 작성된 로직에 대한 테스트 코드를 작성할 때 실패할까 봐 무섭다", "테스트를 하면서 기존의 구조를 바꿔야 할 거 같아 무섭다", "귀찮다" 라는 이유가 가장 컸던 것 같습니다. 하지만 TDD로 개발하게 되면 테스트 코드를 먼저 작성해야 하니 이러한 문제를 원천 차단하게 됩니다.
문서화: 사전에 작성된 테스트 코드 목록과 테스트 코드는 요구 사항을 구체화하는 문서로 활용될 수 있습니다.
재밌다: 작성된 코드의 피드백이 빠르게 되기 때문에 개발이 재밌습니다.
API를 구현할 때 자연스럽게 테스트 코드를 작성하는 것으로 보아
어느 정도 습관이 된 거 같아서 좋다.
'개발' 카테고리의 다른 글
| [Spring] 멀티 테넌시 대응을 위한 DB 라우팅 라이브러리 구현기 (0) | 2025.04.10 |
|---|---|
| TDD 도입하고 개발해보며 체득하기 (0) | 2024.07.14 |
| Google Cloud SQL 로 MySQL 배포하기 (0) | 2024.06.23 |
| [Spring] enum, class에서 @JsonValue 사용법과 자바의 직렬화 (0) | 2024.06.04 |
| Postman으로 STOMP 테스트 하기 (0) | 2024.04.12 |
