ArchUnit Test에 대해 알아보고 적용해보자.
내 프로젝트 아키텍처가 얼마나 일관성 있는지 학습해보자.
1. 히스토리
현재 기능을 먼저 개발하고 테스트 커버리지를 올리고있는 프로젝트가 있다.
해당 프로젝트의 디렉토리 구조나 아키텍처를 손바닥 뒤집듯 고치다보니
얼마나 일관성 있는 구조로 완성되고있는지 테스트가 필요해졌다.
ArchUnit이란?
Java 단위 테스트 프레임워크를 사용하여 Java 코드의 아키텍처를 검사할 수 있는 무료의 간편하고 확장 가능한 라이브러리이자
패키지와 클래스, 레이어와 슬라이스 간의 종속성을 검사하고, 순환 종속성을 검사하는 등 다양한 기능을 포함하고있다
고 한다.
우선 무슨말인지 잘 모르겠다.
선 3줄요악
1. Java / Kotlin 프로젝트 아키텍처 규칙을 검증
2. 코드레벨에서 프로젝트 원칙을 강제 할 수 있음
3. 그래서 쓰면 좋음
테스트 작업은 다음 다이어그램의 순서를 따른다.
2. 테스트 구현 (패키지 구조 테스트)
2.1 ArchUnit 의존성 추가
2.2 ~Service 파일들이 /service 디렉토리 내부에 있는지 테스트
- com.pro.salehero 내부에 있는 아키텍처 테스트한다는 스코프 명시
- @ArchTest 어노테이션을 추가하고
- *Service 파일들이 service 패키지내에 있는지 테스트
결과:
테스트 특)
- 한가지 테스트하면 성공하든 실패하든 불안함
- 2.3으로 개시
2.3 2.2와 같은 맥락으로 컨트롤러 테스트
결과:
다행히(?) 새로 추가한 테스트가 실패했다.
실패했으니 실패 로그를 한번 살펴보자.
(EmailTemplateController.kt:)
테스트가 실패한 이유는 실제로 내가 의도한거처럼 *Controller 클래스가 /controller 패키지 내부에 있지 않아서였으며
위 이미지와 같이 /dto 내부에 있어서 테스트가 실패한거였다.
.... 이후 controller 하위로 수정하여 개선
2.4 리포지토리 테스트
* 리포지토리는 엔티티와 함께 보관하는 구조를 따르고 있어서
* 리포지토리 테스트는 domain 패키지 내부에 있는 경우로 테스트를 진행했다.
대부분 정상적으로 동작했고, 테스트가 한번 실패해서 확인했더니
domain -> doomain으로 잘못적음..
3. 의존성 규칙 테스트
2번 항목에서 패키지안에 알맞은 네이밍 형태를 따르는지 테스트를 해보았다.
ArchUnit테스트로 할 수 있는 테스트들은 더 많다.
이번에는 어떤 네이밍 파일들이 어떤 패키지 파일들에서 호출되는지 테스트 해보았다.
ex) ~Repository를 ~service 패키지 내부의 파일들이 호출되어야 맞지, ~controller에서 호출하면 안됨
3.1 의존성 규칙 테스트용 테스트 생성
* 테스트시 모킹을 위해 의존성 주입을 했을 수 있으니 테스트는 제외하도록 한다.
3.2 테스트 구현부
주요 흐름은 다음과 같다.
*Repository, Service 등의 이름을 가진 파일들이
..service.. 등의 패키지구조에서 호출되는지 테스트
결론:
손바닥 뒤집듯 고친 내 아키텍처들은 매우 불안정한 상태에 있었고
ArchUnit 테스트를 통해 개선 및 구조의 규칙을 확보할 수 있었다.
'공부 > 테스트 코드' 카테고리의 다른 글
| 테스트 더블 (0) | 2025.08.20 |
|---|---|
| TDD 초 기초편 2(SecurityConfig 에러) (0) | 2025.08.10 |
| TDD 초 기초편 (0) | 2025.08.09 |
