[내일배움캠프 TIL] 15일차 - JAVA 프로그램 실행 방법(터미널에서), Clean Test 전략

ReadMe에 실행 방법을 작성하는데,

node에서는 npm run dev , npm install 이런식으로 실행하고, Readme에 이런 명령어들이 적혀있는데,

java에서는 intelliJ를 써서 버튼으로 실행하다보니, 정작 터미널에서는 어떻게 실행하는지 몰라서 궁금해서

찾아 정리해보았습니다.

 

1. Java 프로그램 실행과 Gradle 태스크 환경 구축

기본 실행 명령어: bootRun

• 정체: Spring Boot에서 제공하는 기본 실행 태스크입니다 (./gradlew bootRun).
• 한계: 단순히 프로그램을 실행만 해주기 때문에, DB 정보나 API 키 같은 환경변수를 주입하려면 별도의 복잡한 설정이 필요합니다.

커스텀 태스크 dev를 만든 이유 (환경변수 주입)

• 문제: 로컬 개발 시 .env 파일에 저장된 환경변수들을 매번 수동으로 설정하는 것은 번거롭고 펌웨어 설정값 관리하듯 실수가 생길 수 있습니다.
• 해결: bootRun 대신 .env 파일을 읽어 자동으로 환경변수를 세팅해 주는 dev 태스크를 직접 만들었습니다.
• 효과: ./gradlew dev 한 줄로 환경변수가 완벽히 세팅된 개발 환경을 구축했습니다.

gradlew (Gradle Wrapper)의 역할

• 프로젝트 내부에 포함된 실행 스크립트로, 별도의 Gradle 설치 없이도 프로젝트가 지정한 버전을 그대로 사용하여 실행 환경의 일관성을 유지해 줍니다.

// build.gradle 예시
tasks.register('dev', JavaExec) {
    mainClass = 'com.ldif.delivery.DeliveryApplication'
    classpath = sourceSets.main.runtimeClasspath
    
    // .env 파일을 읽어 Java 실행 환경(Environment)에 직접 주입!
    if (file(".env").exists()) {
        file(".env").readLines().each { line ->
            // ... (환경변수 파싱 로직)
            environment key, value 
        }
    }
}

효과: ./gradlew dev 명령 한 줄로 환경변수가 주입된 개발 서버를 즉시 실행할 수 있습니다.

 

 

2. Mockito의 Stubbing과 청결한 테스트(Clean Test)

Stubbing(스터빙)의 정의

• 테스트 로직이 의존하는 가짜 객체(Mock)에게 "이런 요청이 오면 이렇게 대답해"라고 미리 대본을 짜주는 것입니다.

Mockito의 철학: "테스트 코드의 청결함(Cleanliness)"

오늘 발생한 UnnecessaryStubbingException은 Mockito가 코드를 더 깨끗하게 유지하라고 던지는 조언입니다.

• 가독성 저하: 사용하지 않는 Stubbing이 많으면, 나중에 코드를 읽는 동료가 "이게 왜 필요하지? 로직에 영향을 주나?" 하고 불필요한 분석을 하게 만듭니다.
• 유지보수의 적: 로직이 변경되어 특정 호출이 필요 없어졌는데도 Stubbing이 남아있다면, 테스트 코드는 로직의 실체를 반영하지 못하는 '거짓 문서'가 됩니다.
• 결론: Mockito는 **"정말 필요한 상황(Given)만 정의하고, 불필요한 설정은 제거하라"**는 원칙을 강제하여 테스트 코드의 신뢰도를 높입니다.

---

3. 실전 테스트 리팩토링 핵심

• @BeforeEach 활용: 모든 테스트에서 공통으로 필요한 '유저 권한 무적권' 등을 분리하여 각 테스트 메서드가 본연의 검증 로직에만 집중하도록 개선했습니다.
• 변수 범위(Scope): setUp()의 지역 변수를 클래스 필드로 승격시켜 메서드 간의 데이터 공유 문제를 해결했습니다.