ArchUnit 테스트 도입 제안

[Seol-JY]

프로젝트 규모 확장에 따른 아키텍처 일관성 유지를 위해 ArchUnit 테스트 도입을 제안합니다.

ArchUnit 개요

ArchUnit은 Java 코드베이스의 아키텍처를 검증하는 라이브러리입니다.

주요 특징은 다음과 같습니다:

1. Java 코드 기반 테스트: JUnit 등 표준 단위 테스트 프레임워크와 통합
2. 유연한 규칙 정의: 사전 정의 및 사용자 정의 규칙 작성 가능
3. 표현력 있는 API: 복잡한 아키텍처 규칙을 명확하게 표현

예시 코드:

@Test
void servicesShouldNotDependOnPresentationLayer() {
    JavaClasses importedClasses = new ClassFileImporter().importPackages("com.myapp");

    ArchRule rule = noClasses()
        .that().resideInAPackage("..service..")
        .should().dependOnClassesThat().resideInAPackage("..controller..")
        .because("Services should not depend on the presentation layer");

    rule.check(importedClasses);
}

이 예시는 서비스 레이어가 프레젠테이션 레이어에 의존하지 않아야 한다는 규칙을 검증합니다.

도입의 장점

1. 자동화된 아키텍처 검증:

   • 수동 코드 리뷰 부담 감소
   • 일관된 아키텍처 규칙 적용 (예: 레이어 의존성, 패키지 구조)

2. 조기 오류 감지:

   • 개발 초기 단계에서 아키텍처 위반 식별
   • 문제 누적 전 신속한 수정 가능

3. 실행 가능한 문서화:

   • 아키텍처 규칙을 코드로 명시
   • 신규 팀원 온보딩 및 지식 공유 개선

4. 리팩토링 안전성:

   • 대규모 리팩토링 시 아키텍처 일관성 보장
   • 변경 영향 즉시 파악

5. 기술 부채 관리:

   • 아키텍처 관련 기술 부채 축적 방지
   • 지속적 코드 품질 개선

고려 사항

1. 초기 설정 비용:

   • 규칙 정의 및 테스트 작성에 시간 소요
   • 팀 전체의 학습 필요

2. 유지보수:

   • 프로젝트 진화에 따른 규칙 업데이트 필요
   • false positive 처리를 위한 지속적 관리

false positive란?

"False positive"란 ArchUnit이 아키텍처 위반으로 잘못 식별한 케이스를 말합니다.

이는 다음과 같은 경우에 발생할 수 있습니다:

1. 규칙이 너무 엄격하게 정의된 경우
2. 정당한 예외 상황이 존재하는 경우
3. 프로젝트의 특수한 요구사항과 규칙이 충돌하는 경우

예를 들어, 일반적으로 서비스 레이어는 컨트롤러 레이어에 의존해서는 안 되지만, 특정 기능에서는 이러한 의존성이 필요할 수 있습니다.

False positive 관리를 위해 다음과 같은 작업이 필요합니다:

• 규칙 재검토 및 미세 조정
• 예외 처리 메커니즘 구현 (예: 특정 클래스나 패키지에 대한 규칙 예외 설정)
• 팀 내 논의를 통한 규칙 합의 및 문서화

ArchUnit 도입은 장기적으로 프로젝트 품질과 유지보수성을 크게 향상시킬 것으로 기대합니다. 아키텍처 일관성 유지, 개발 생산성 향상, 코드 품질 개선 측면에서 상당한 이점이 있을것으로 보입니다.

추가 질문이나 우려 사항이 있다면 자유롭게 논의해 주세요.

참고 링크:
https://d2.naver.com/helloworld/9222129

[Seol-JY]

초기에 아키텍쳐 관련해서 테스트를 잘 작성해 두면, 별도로 추가하거나 수정할 일은 잘 없을 것 같습니다.

[Junad-Park]

참고 링크를 살펴보다가

규칙: Support 패키지는 다른 패키지에 의존할 수 없다

라는 규칙을 발견 했는데, 어떤 패키지가 다른 패키지에 의존할 수 없다라는 규칙은 적용하지 않고 진행하는걸까요?

[Seol-JY]

@Junad-Park 실제로 적용하게 된다면, 회의를 통해서 아키텍쳐 관련 제약사항을 확실히 확정한 후에 적용할 것 같습니다! 프로젝트 성격에 맞도록요