🚀 시작하기 전에: 왜 테스트가 중요할까?

안녕! 오늘은 개발자라면 반드시 알아야 할 테스팅 프레임워크와 TDD(Test-Driven Development)에 대해 이야기해볼게. 😊

혹시 이런 경험 있어? 코드를 열심히 짜고 나서 실행했는데 예상치 못한 버그가 튀어나와서 밤새 디버깅한 적 말이야. 아니면 다른 사람이 짠 코드를 수정했는데, 어디선가 오류가 발생해서 당황했던 경험? 🤯

바로 이런 문제들을 해결하기 위해 등장한 게 테스팅 프레임워크와 TDD 방법론이야. 이건 단순히 버그를 찾는 도구가 아니라, 코드의 품질을 높이고 개발자의 자신감을 키워주는 강력한 무기지!

📚 TDD(Test-Driven Development)란 무엇인가?

TDD는 테스트 주도 개발이라고 불러. 말 그대로 테스트가 개발을 이끌어가는 방법론이지. 일반적인 개발 방식과는 순서가 완전히 반대야! 😲

보통은 이렇게 개발하잖아?
1️⃣ 기능 구현 → 2️⃣ 테스트 작성 → 3️⃣ 버그 발견 → 4️⃣ 수정

하지만 TDD는 이렇게 해:
1️⃣ 테스트 작성 → 2️⃣ 테스트 실패 확인 → 3️⃣ 최소한의 코드 구현 → 4️⃣ 테스트 통과 → 5️⃣ 리팩토링

🔄 TDD의 핵심 사이클: Red-Green-Refactor

TDD의 핵심은 Red-Green-Refactor 사이클이야. 이게 뭐냐면:

🔴 Red (실패하는 테스트 작성)
먼저 실패하는 테스트를 작성해. "이 기능은 이렇게 동작해야 해!"라는 명세를 테스트 코드로 표현하는 거지. 당연히 아직 구현 코드가 없으니까 테스트는 실패할 거야.

🟢 Green (테스트를 통과하는 최소한의 코드 작성)
이제 테스트를 통과시키기 위한 최소한의 코드만 작성해. 여기서 중요한 건 "최소한"이야. 완벽한 코드를 짜려고 하지 말고, 일단 테스트만 통과시켜!

🔵 Refactor (코드 개선)
테스트가 통과했다면, 이제 코드를 깔끔하게 정리할 시간이야. 중복 제거, 가독성 향상, 성능 최적화 등을 진행하되, 테스트는 계속 통과해야 해.

🤔 TDD의 단점과 한계

물론 TDD가 만능은 아니야. 솔직히 말하면 이런 어려움들이 있어:

⏰ 초기 개발 시간 증가
테스트 코드를 먼저 작성하니까 당연히 시간이 더 걸려. 특히 TDD에 익숙하지 않으면 개발 속도가 확 느려질 수 있어.

📈 학습 곡선
TDD는 단순히 테스트 코드 작성법만 배우면 되는 게 아니야. 사고방식 자체를 바꿔야 하거든. 이게 생각보다 쉽지 않아.

🎨 UI/UX 테스트의 어려움
사용자 인터페이스나 디자인 관련 부분은 TDD로 접근하기가 까다로워. 시각적인 부분을 자동화 테스트로 검증하기는 어렵거든.

🔧 레거시 코드 적용 난이도
이미 만들어진 프로젝트에 TDD를 적용하려면 엄청난 노력이 필요해. 기존 코드를 테스트 가능하게 리팩토링하는 것부터가 큰 산이야.

☕ JUnit: 자바 테스팅의 표준

JUnit은 자바 진영에서 가장 널리 사용되는 테스팅 프레임워크야. 2000년에 처음 등장한 이후로 지금까지 자바 개발자들의 필수 도구로 자리잡았지. 현재는 JUnit 5(JUnit Jupiter)가 최신 버전이야. 🎉

🌟 JUnit의 주요 특징

1. 어노테이션 기반의 직관적인 구조
JUnit은 어노테이션을 사용해서 테스트 메서드를 정의해. 코드만 봐도 뭐하는 건지 바로 알 수 있어.

2. 풍부한 Assertion 메서드
다양한 검증 메서드를 제공해서 거의 모든 상황에 대응할 수 있어.

3. 테스트 라이프사이클 관리
테스트 실행 전후로 필요한 작업들을 체계적으로 관리할 수 있어.

4. 파라미터화 테스트
같은 테스트를 여러 입력값으로 반복 실행할 수 있어.

💻 JUnit 5 기본 구조

JUnit 5는 세 가지 주요 모듈로 구성되어 있어:

JUnit Platform: 테스트를 실행하는 기반 플랫폼
JUnit Jupiter: JUnit 5의 새로운 프로그래밍 모델과 확장 모델
JUnit Vintage: JUnit 3, 4로 작성된 테스트를 실행하기 위한 엔진

📝 JUnit 주요 어노테이션

🔍 JUnit 실전 예제

간단한 계산기 클래스를 테스트하는 예제를 볼까? 실제로 어떻게 사용하는지 감을 잡을 수 있을 거야.

import org.junit.jupiter.api.*;
import static org.junit.jupiter.api.Assertions.*;

@DisplayName("계산기 테스트")
class CalculatorTest {
    
    private Calculator calculator;
    
    @BeforeEach
    void setUp() {
        calculator = new Calculator();
        System.out.println("테스트 준비 완료!");
    }
    
    @Test
    @DisplayName("두 숫자의 덧셈이 정확한지 확인")
    void testAddition() {
        // Given (준비)
        int a = 5;
        int b = 3;
        
        // When (실행)
        int result = calculator.add(a, b);
        
        // Then (검증)
        assertEquals(8, result, "5 + 3은 8이어야 합니다");
    }
    
    @Test
    @DisplayName("0으로 나누면 예외가 발생하는지 확인")
    void testDivisionByZero() {
        assertThrows(ArithmeticException.class, () -> {
            calculator.divide(10, 0);
        }, "0으로 나누면 ArithmeticException이 발생해야 합니다");
    }
    
    @ParameterizedTest
    @DisplayName("여러 숫자 조합의 곱셈 테스트")
    @CsvSource({
        "2, 3, 6",
        "5, 4, 20",
        "10, 0, 0"
    })
    void testMultiplication(int a, int b, int expected) {
        assertEquals(expected, calculator.multiply(a, b));
    }
    
    @AfterEach
    void tearDown() {
        System.out.println("테스트 정리 완료!");
    }
}

위 코드를 보면 테스트의 구조가 명확하게 보이지? Given-When-Then 패턴을 사용하면 테스트 코드의 가독성이 훨씬 좋아져. 이건 TDD에서 자주 사용하는 패턴이야.

Given: 테스트를 위한 준비 단계
When: 실제로 테스트할 동작을 실행
Then: 결과를 검증

🎯 JUnit Assertions 완벽 가이드

JUnit의 Assertions 클래스는 다양한 검증 메서드를 제공해. 자주 사용하는 것들을 정리해볼게:

@Test
@DisplayName("assertAll을 사용한 그룹 검증")
void testPersonDetails() {
    Person person = new Person("홍길동", 30, "hong@example.com");
    
    assertAll("person 정보 검증",
        () -> assertEquals("홍길동", person.getName()),
        () -> assertEquals(30, person.getAge()),
        () -> assertTrue(person.getEmail().contains("@")),
        () -> assertNotNull(person.getId())
    );
}

🚀 JUnit 5의 새로운 기능들

JUnit 5는 이전 버전에 비해 많은 개선이 있었어. 특히 주목할 만한 기능들을 소개할게:

1. 동적 테스트 (Dynamic Tests)
런타임에 테스트를 생성할 수 있어. 테스트 데이터가 동적으로 결정될 때 유용해.

@TestFactory
@DisplayName("동적 테스트 생성")
Stream<DynamicTest> dynamicTestsFromStream() {
    return Stream.of(2, 4, 6, 8, 10)
        .map(number -> DynamicTest.dynamicTest(
            "짝수 테스트: " + number,
            () -> assertTrue(number % 2 == 0)
        ));
}

2. 중첩 테스트 (Nested Tests)
테스트를 계층적으로 구조화할 수 있어. 관련된 테스트들을 그룹화하기 좋아.

@DisplayName("쇼핑카트 테스트")
class ShoppingCartTest {
    
    @Nested
    @DisplayName("빈 카트일 때")
    class WhenEmpty {
        
        @Test
        @DisplayName("총액은 0이어야 한다")
        void totalShouldBeZero() {
            ShoppingCart cart = new ShoppingCart();
            assertEquals(0, cart.getTotal());
        }
    }
    
    @Nested
    @DisplayName("상품이 있을 때")
    class WhenHasItems {
        
        @Test
        @DisplayName("총액은 상품 가격의 합이어야 한다")
        void totalShouldBeSumOfItems() {
            ShoppingCart cart = new ShoppingCart();
            cart.addItem(new Item("책", 15000));
            cart.addItem(new Item("펜", 1000));
            assertEquals(16000, cart.getTotal());
        }
    }
}

3. 조건부 테스트 실행
특정 조건에서만 테스트를 실행하거나 건너뛸 수 있어.

@Test
@EnabledOnOs(OS.WINDOWS)
@DisplayName("윈도우에서만 실행")
void testOnWindows() {
    // 윈도우 전용 테스트
}

@Test
@EnabledIfEnvironmentVariable(named = "ENV", matches = "production")
@DisplayName("프로덕션 환경에서만 실행")
void testOnProduction() {
    // 프로덕션 환경 테스트
}

@Test
@EnabledIf("customCondition")
@DisplayName("커스텀 조건이 참일 때만 실행")
void testWithCustomCondition() {
    // 조건부 테스트
}

boolean customCondition() {
    return LocalDate.now().getDayOfWeek() == DayOfWeek.MONDAY;
}

🎭 TestNG: 더 강력한 테스팅 프레임워크

TestNG는 "Testing Next Generation"의 약자야. JUnit에서 영감을 받아 만들어졌지만, 더 강력하고 유연한 기능들을 제공해. 특히 대규모 테스트 스위트를 관리하거나 복잡한 테스트 시나리오를 구성할 때 빛을 발해. 🌟

🆚 JUnit vs TestNG: 무엇이 다를까?

많은 사람들이 "JUnit이 있는데 왜 TestNG를 써야 하나요?"라고 물어봐. 좋은 질문이야! 둘 다 훌륭한 프레임워크지만, 각자의 강점이 있어.

📋 TestNG 주요 어노테이션

TestNG의 어노테이션은 JUnit과 비슷하지만 더 많은 옵션을 제공해:

import org.testng.annotations.*;
import static org.testng.Assert.*;

public class TestNGExample {
    
    @BeforeSuite
    public void beforeSuite() {
        System.out.println("전체 테스트 스위트 시작 전 실행");
    }
    
    @BeforeTest
    public void beforeTest() {
        System.out.println("테스트 태그 시작 전 실행");
    }
    
    @BeforeClass
    public void beforeClass() {
        System.out.println("현재 클래스의 첫 테스트 전 실행");
    }
    
    @BeforeMethod
    public void beforeMethod() {
        System.out.println("각 테스트 메서드 전 실행");
    }
    
    @Test(priority = 1)
    public void testLogin() {
        System.out.println("로그인 테스트 - 우선순위 1");
        assertTrue(true);
    }
    
    @Test(priority = 2, dependsOnMethods = {"testLogin"})
    public void testDashboard() {
        System.out.println("대시보드 테스트 - 로그인 후 실행");
        assertTrue(true);
    }
    
    @AfterMethod
    public void afterMethod() {
        System.out.println("각 테스트 메서드 후 실행");
    }
    
    @AfterClass
    public void afterClass() {
        System.out.println("현재 클래스의 마지막 테스트 후 실행");
    }
    
    @AfterTest
    public void afterTest() {
        System.out.println("테스트 태그 종료 후 실행");
    }
    
    @AfterSuite
    public void afterSuite() {
        System.out.println("전체 테스트 스위트 종료 후 실행");
    }
}

보다시피 TestNG는 테스트 라이프사이클을 더 세밀하게 제어할 수 있어. @BeforeSuite와 @AfterSuite는 전체 테스트 실행의 시작과 끝에 한 번씩만 실행돼. 데이터베이스 연결이나 서버 시작 같은 비용이 큰 작업에 딱이야!

🎯 TestNG의 강력한 기능들

1. 그룹 테스트
테스트를 논리적인 그룹으로 묶어서 선택적으로 실행할 수 있어.

@Test(groups = {"smoke", "regression"})
public void testCriticalFeature() {
    // 중요한 기능 테스트
}

@Test(groups = {"regression"})
public void testDetailedFeature() {
    // 상세한 기능 테스트
}

@Test(groups = {"smoke"})
public void testBasicFeature() {
    // 기본 기능 테스트
}

XML 설정 파일에서 특정 그룹만 실행하도록 지정할 수 있어:

<suite name="Test Suite">
    <test name="Smoke Tests">
        <groups>
            <run>
                <include name="smoke"/>
            </run>
        </groups>
        <classes>
            <class name="com.example.TestClass"/>
        </classes>
    </test>
</suite>

2. 데이터 프로바이더 (Data Provider)
같은 테스트를 다양한 데이터로 반복 실행할 때 정말 유용해. JUnit의 파라미터화 테스트보다 훨씬 강력해!

@DataProvider(name = "loginData")
public Object[][] createLoginData() {
    return new Object[][] {
        {"user1@example.com", "password123", true},
        {"user2@example.com", "wrongpass", false},
        {"invalid@email", "password123", false},
        {"", "", false}
    };
}

@Test(dataProvider = "loginData")
public void testLogin(String email, String password, boolean expectedResult) {
    LoginService service = new LoginService();
    boolean result = service.login(email, password);
    assertEquals(result, expectedResult, 
        "로그인 결과가 예상과 다릅니다: " + email);
}

데이터 프로바이더는 메서드뿐만 아니라 파일이나 데이터베이스에서도 데이터를 가져올 수 있어. 실전에서 정말 유용한 기능이야!

3. 의존성 테스트
TestNG의 독특한 기능 중 하나야. 테스트 간의 의존 관계를 명시할 수 있어.

@Test
public void serverStartedOk() {
    // 서버 시작 테스트
    assertTrue(server.isRunning());
}

@Test(dependsOnMethods = {"serverStartedOk"})
public void testDatabaseConnection() {
    // 서버가 실행 중일 때만 DB 연결 테스트
    assertTrue(database.isConnected());
}

@Test(dependsOnMethods = {"testDatabaseConnection"})
public void testDataRetrieval() {
    // DB 연결이 성공했을 때만 데이터 조회 테스트
    assertNotNull(database.getData());
}

만약 serverStartedOk 테스트가 실패하면, 의존하는 다른 테스트들은 자동으로 건너뛰어져. 불필요한 테스트 실행을 막을 수 있어서 효율적이야!

4. 병렬 실행
TestNG는 테스트를 병렬로 실행하는 기능이 내장되어 있어. XML 설정만으로 간단하게 활성화할 수 있어.

<suite name="Parallel Suite" parallel="methods" thread-count="5">
    <test name="Parallel Test">
        <classes>
            <class name="com.example.TestClass1"/>
            <class name="com.example.TestClass2"/>
        </classes>
    </test>
</suite>

parallel 속성으로 병렬화 수준을 조절할 수 있어:
- methods: 메서드 단위로 병렬 실행
- classes: 클래스 단위로 병렬 실행
- tests: 테스트 태그 단위로 병렬 실행
- instances: 인스턴스 단위로 병렬 실행

📊 TestNG 리포팅

TestNG는 기본적으로 HTML 리포트를 생성해줘. 테스트 결과를 시각적으로 확인하기 정말 좋아. 게다가 커스텀 리스너를 만들어서 원하는 형태의 리포트를 생성할 수도 있어.

public class CustomListener implements ITestListener {
    
    @Override
    public void onTestStart(ITestResult result) {
        System.out.println("테스트 시작: " + result.getName());
    }
    
    @Override
    public void onTestSuccess(ITestResult result) {
        System.out.println("테스트 성공: " + result.getName());
    }
    
    @Override
    public void onTestFailure(ITestResult result) {
        System.out.println("테스트 실패: " + result.getName());
        // 스크린샷 캡처, 로그 저장 등
    }
    
    @Override
    public void onTestSkipped(ITestResult result) {
        System.out.println("테스트 건너뜀: " + result.getName());
    }
}

리스너를 테스트 클래스에 적용하려면:

@Listeners(CustomListener.class)
public class MyTest {
    // 테스트 메서드들
}

🎪 Mockito: 모킹의 마법사

자, 이제 정말 재미있는 부분으로 왔어! Mockito는 모킹(Mocking) 프레임워크야. "모킹이 뭐냐고?" 좋은 질문이야! 😊

실제 개발에서는 테스트하려는 코드가 데이터베이스, 외부 API, 파일 시스템 같은 외부 의존성을 가지고 있는 경우가 많아. 이런 걸 실제로 연결해서 테스트하면 여러 문제가 생겨:

❌ 테스트가 느려져
❌ 외부 시스템의 상태에 따라 테스트 결과가 달라져
❌ 비용이 발생할 수 있어 (API 호출 비용 등)
❌ 특정 상황(에러 상황 등)을 재현하기 어려워

바로 이럴 때 Mock 객체를 사용하는 거야! Mock 객체는 실제 객체를 흉내내는 가짜 객체인데, 우리가 원하는 대로 동작하도록 프로그래밍할 수 있어. 🎭

🌟 Mockito의 핵심 개념

1. Mock 객체 생성
Mockito로 Mock 객체를 만드는 건 정말 간단해.

import static org.mockito.Mockito.*;

// 방법 1: mock() 메서드 사용
UserRepository mockRepository = mock(UserRepository.class);

// 방법 2: @Mock 어노테이션 사용
@Mock
private UserRepository mockRepository;

// @Mock을 사용하려면 초기화가 필요해
@BeforeEach
void setUp() {
    MockitoAnnotations.openMocks(this);
}

2. Stubbing (동작 정의)
Mock 객체가 어떻게 동작할지 정의하는 거야. "이 메서드가 호출되면 이런 값을 반환해!"라고 지정하는 거지.

// 특정 인자로 호출되면 특정 값 반환
when(mockRepository.findById(1L))
    .thenReturn(new User(1L, "홍길동"));

// 어떤 인자로 호출되든 같은 값 반환
when(mockRepository.findById(anyLong()))
    .thenReturn(new User(1L, "홍길동"));

// 예외 발생시키기
when(mockRepository.findById(999L))
    .thenThrow(new UserNotFoundException("사용자를 찾을 수 없습니다"));

// 여러 번 호출될 때 다른 값 반환
when(mockRepository.count())
    .thenReturn(10L)
    .thenReturn(20L)
    .thenReturn(30L);

3. Verification (검증)
Mock 객체의 메서드가 실제로 호출되었는지, 몇 번 호출되었는지 검증할 수 있어.

// 메서드가 호출되었는지 확인
verify(mockRepository).findById(1L);

// 정확히 n번 호출되었는지 확인
verify(mockRepository, times(3)).findAll();

// 최소 n번 호출되었는지 확인
verify(mockRepository, atLeast(1)).save(any(User.class));

// 최대 n번 호출되었는지 확인
verify(mockRepository, atMost(5)).delete(any(User.class));

// 한 번도 호출되지 않았는지 확인
verify(mockRepository, never()).deleteAll();

// 호출 순서 검증
InOrder inOrder = inOrder(mockRepository);
inOrder.verify(mockRepository).findById(1L);
inOrder.verify(mockRepository).save(any(User.class));

💡 Mockito 실전 예제

이론만 보면 좀 추상적이지? 실제 예제를 통해 Mockito가 얼마나 유용한지 보여줄게!

사용자 서비스를 테스트한다고 가정해보자. 이 서비스는 UserRepository에 의존하고 있어.

// 테스트할 실제 클래스
public class UserService {
    private UserRepository userRepository;
    private EmailService emailService;
    
    public UserService(UserRepository userRepository, EmailService emailService) {
        this.userRepository = userRepository;
        this.emailService = emailService;
    }
    
    public User registerUser(String name, String email) {
        // 이메일 중복 체크
        if (userRepository.existsByEmail(email)) {
            throw new DuplicateEmailException("이미 존재하는 이메일입니다");
        }
        
        // 사용자 생성
        User user = new User(name, email);
        User savedUser = userRepository.save(user);
        
        // 환영 이메일 발송
        emailService.sendWelcomeEmail(email);
        
        return savedUser;
    }
    
    public User getUserById(Long id) {
        return userRepository.findById(id)
            .orElseThrow(() -> new UserNotFoundException("사용자를 찾을 수 없습니다"));
    }
}

이제 이 서비스를 Mockito로 테스트해보자:

import org.junit.jupiter.api.*;
import org.mockito.*;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.*;

class UserServiceTest {
    
    @Mock
    private UserRepository userRepository;
    
    @Mock
    private EmailService emailService;
    
    @InjectMocks
    private UserService userService;
    
    @BeforeEach
    void setUp() {
        MockitoAnnotations.openMocks(this);
    }
    
    @Test
    @DisplayName("새 사용자 등록 성공")
    void testRegisterUser_Success() {
        // Given
        String name = "김철수";
        String email = "kim@example.com";
        User expectedUser = new User(1L, name, email);
        
        when(userRepository.existsByEmail(email)).thenReturn(false);
        when(userRepository.save(any(User.class))).thenReturn(expectedUser);
        
        // When
        User result = userService.registerUser(name, email);
        
        // Then
        assertNotNull(result);
        assertEquals(name, result.getName());
        assertEquals(email, result.getEmail());
        
        // 메서드 호출 검증
        verify(userRepository).existsByEmail(email);
        verify(userRepository).save(any(User.class));
        verify(emailService).sendWelcomeEmail(email);
    }
    
    @Test
    @DisplayName("중복 이메일로 등록 시도 시 예외 발생")
    void testRegisterUser_DuplicateEmail() {
        // Given
        String email = "duplicate@example.com";
        when(userRepository.existsByEmail(email)).thenReturn(true);
        
        // When & Then
        assertThrows(DuplicateEmailException.class, () -> {
            userService.registerUser("테스트", email);
        });
        
        // save와 이메일 발송은 호출되지 않아야 함
        verify(userRepository, never()).save(any(User.class));
        verify(emailService, never()).sendWelcomeEmail(anyString());
    }
    
    @Test
    @DisplayName("존재하지 않는 사용자 조회 시 예외 발생")
    void testGetUserById_NotFound() {
        // Given
        Long userId = 999L;
        when(userRepository.findById(userId)).thenReturn(Optional.empty());
        
        // When & Then
        assertThrows(UserNotFoundException.class, () -> {
            userService.getUserById(userId);
        });
    }
}

보다시피 실제 데이터베이스나 이메일 서버 없이도 완벽하게 테스트할 수 있어! @InjectMocks 어노테이션은 Mock 객체들을 자동으로 주입해줘서 정말 편리해. 🎉

🎯 Mockito의 고급 기능들

1. ArgumentCaptor (인자 캡처)
Mock 메서드에 전달된 인자를 캡처해서 검증할 수 있어. 복잡한 객체가 전달될 때 특히 유용해.

@Test
void testArgumentCaptor() {
    // Given
    ArgumentCaptor<User> userCaptor = ArgumentCaptor.forClass(User.class);
    
    // When
    userService.registerUser("이영희", "lee@example.com");
    
    // Then
    verify(userRepository).save(userCaptor.capture());
    User capturedUser = userCaptor.getValue();
    
    assertEquals("이영희", capturedUser.getName());
    assertEquals("lee@example.com", capturedUser.getEmail());
}

2. Answer (커스텀 동작)
더 복잡한 동작이 필요할 때는 Answer를 사용할 수 있어.

when(mockRepository.save(any(User.class))).thenAnswer(invocation -> {
    User user = invocation.getArgument(0);
    user.setId(100L); // ID 자동 생성 시뮬레이션
    user.setCreatedAt(LocalDateTime.now());
    return user;
});

3. Spy (부분 모킹)
실제 객체를 사용하되 일부 메서드만 모킹하고 싶을 때 Spy를 사용해.

@Spy
private UserService userService;

@Test
void testWithSpy() {
    // 실제 메서드는 그대로 사용하되, 특정 메서드만 모킹
    doReturn(new User(1L, "테스트")).when(userService).getUserById(1L);
    
    // 다른 메서드들은 실제로 실행됨
    User user = userService.getUserById(1L);
    assertNotNull(user);
}

4. BDD 스타일 (given-when-then)
Mockito는 BDD(Behavior-Driven Development) 스타일도 지원해. 코드가 더 읽기 쉬워져.

import static org.mockito.BDDMockito.*;

@Test
void testBDDStyle() {
    // Given
    given(userRepository.findById(1L))
        .willReturn(Optional.of(new User(1L, "테스트")));
    
    // When
    User user = userService.getUserById(1L);
    
    // Then
    then(userRepository).should().findById(1L);
    assertNotNull(user);
}

⚠️ Mockito 사용 시 주의사항

🔧 실전 프로젝트에 TDD 적용하기

이론은 충분히 배웠으니, 이제 실제 프로젝트에 어떻게 적용하는지 알아보자! 많은 개발자들이 TDD를 배우고도 실전에서 막막해하는 경우가 많아. 그래서 단계별로 자세히 설명해줄게. 😊

🎬 프로젝트 시작하기

간단한 도서 관리 시스템을 TDD로 만들어보자. 책을 추가하고, 조회하고, 대여하는 기능을 구현할 거야.

먼저 무엇을 만들지 명확히 해야 해. 요구사항을 작은 단위로 쪼개보자:

📌 책 추가 기능
- 제목, 저자, ISBN을 입력받아 책을 추가한다
- 같은 ISBN의 책은 중복 추가할 수 없다
- 필수 정보가 누락되면 예외를 발생시킨다

📌 책 조회 기능
- ISBN으로 책을 조회할 수 있다
- 존재하지 않는 책을 조회하면 예외를 발생시킨다
- 모든 책 목록을 조회할 수 있다

📌 책 대여 기능
- 사용자가 책을 대여할 수 있다
- 이미 대여 중인 책은 대여할 수 없다
- 대여 기록을 남긴다

가장 간단한 기능부터 시작하자. 책을 추가하는 기능의 테스트를 먼저 작성해.

import org.junit.jupiter.api.*;
import static org.junit.jupiter.api.Assertions.*;

class BookServiceTest {
    
    private BookService bookService;
    private BookRepository bookRepository;
    
    @BeforeEach
    void setUp() {
        bookRepository = new InMemoryBookRepository();
        bookService = new BookService(bookRepository);
    }
    
    @Test
    @DisplayName("책을 성공적으로 추가할 수 있다")
    void testAddBook_Success() {
        // Given
        String title = "클린 코드";
        String author = "로버트 C. 마틴";
        String isbn = "978-8966260959";
        
        // When
        Book book = bookService.addBook(title, author, isbn);
        
        // Then
        assertNotNull(book);
        assertEquals(title, book.getTitle());
        assertEquals(author, book.getAuthor());
        assertEquals(isbn, book.getIsbn());
        assertFalse(book.isRented());
    }
}

이 테스트를 실행하면 당연히 실패해. BookService도, Book 클래스도 아직 없으니까! 이게 바로 Red 단계야. 🔴

이제 테스트를 통과시키기 위한 최소한의 코드를 작성하자.

// Book 클래스
public class Book {
    private String title;
    private String author;
    private String isbn;
    private boolean rented;
    
    public Book(String title, String author, String isbn) {
        this.title = title;
        this.author = author;
        this.isbn = isbn;
        this.rented = false;
    }
    
    // Getters
    public String getTitle() { return title; }
    public String getAuthor() { return author; }
    public String getIsbn() { return isbn; }
    public boolean isRented() { return rented; }
}

// BookRepository 인터페이스
public interface BookRepository {
    Book save(Book book);
    Optional<Book> findByIsbn(String isbn);
    List<Book> findAll();
    boolean existsByIsbn(String isbn);
}

// BookService 클래스
public class BookService {
    private BookRepository bookRepository;
    
    public BookService(BookRepository bookRepository) {
        this.bookRepository = bookRepository;
    }
    
    public Book addBook(String title, String author, String isbn) {
        Book book = new Book(title, author, isbn);
        return bookRepository.save(book);
    }
}

테스트를 실행하면 통과할 거야! 🟢 하지만 아직 검증 로직이 없어. 다음 테스트를 작성하자.

@Test
@DisplayName("중복된 ISBN으로 책을 추가하면 예외가 발생한다")
void testAddBook_DuplicateIsbn() {
    // Given
    String isbn = "978-8966260959";
    bookService.addBook("클린 코드", "로버트 C. 마틴", isbn);
    
    // When & Then
    assertThrows(DuplicateIsbnException.class, () -> {
        bookService.addBook("다른 책", "다른 저자", isbn);
    });
}

@Test
@DisplayName("필수 정보가 누락되면 예외가 발생한다")
void testAddBook_MissingRequiredFields() {
    assertThrows(IllegalArgumentException.class, () -> {
        bookService.addBook(null, "저자", "123");
    });
    
    assertThrows(IllegalArgumentException.class, () -> {
        bookService.addBook("제목", null, "123");
    });
    
    assertThrows(IllegalArgumentException.class, () -> {
        bookService.addBook("제목", "저자", null);
    });
}

이 테스트들을 통과시키기 위해 BookService를 개선하자:

public class BookService {
    private BookRepository bookRepository;
    
    public BookService(BookRepository bookRepository) {
        this.bookRepository = bookRepository;
    }
    
    public Book addBook(String title, String author, String isbn) {
        // 입력 검증
        validateBookInfo(title, author, isbn);
        
        // 중복 체크
        if (bookRepository.existsByIsbn(isbn)) {
            throw new DuplicateIsbnException("이미 존재하는 ISBN입니다: " + isbn);
        }
        
        Book book = new Book(title, author, isbn);
        return bookRepository.save(book);
    }
    
    private void validateBookInfo(String title, String author, String isbn) {
        if (title == null || title.trim().isEmpty()) {
            throw new IllegalArgumentException("책 제목은 필수입니다");
        }
        if (author == null || author.trim().isEmpty()) {
            throw new IllegalArgumentException("저자는 필수입니다");
        }
        if (isbn == null || isbn.trim().isEmpty()) {
            throw new IllegalArgumentException("ISBN은 필수입니다");
        }
    }
}

실제 프로젝트에서는 데이터베이스를 사용할 거야. Mockito로 Repository를 모킹해서 테스트하자.

import org.mockito.*;
import static org.mockito.Mockito.*;

class BookServiceWithMockTest {
    
    @Mock
    private BookRepository bookRepository;
    
    @InjectMocks
    private BookService bookService;
    
    @BeforeEach
    void setUp() {
        MockitoAnnotations.openMocks(this);
    }
    
    @Test
    @DisplayName("책 추가 시 Repository의 save가 호출된다")
    void testAddBook_CallsRepositorySave() {
        // Given
        String title = "이펙티브 자바";
        String author = "조슈아 블로크";
        String isbn = "978-8966262281";
        
        when(bookRepository.existsByIsbn(isbn)).thenReturn(false);
        when(bookRepository.save(any(Book.class)))
            .thenAnswer(invocation -> invocation.getArgument(0));
        
        // When
        Book book = bookService.addBook(title, author, isbn);
        
        // Then
        verify(bookRepository).existsByIsbn(isbn);
        verify(bookRepository).save(any(Book.class));
        assertNotNull(book);
    }
    
    @Test
    @DisplayName("대여 기능 테스트")
    void testRentBook() {
        // Given
        String isbn = "978-8966260959";
        String userId = "user123";
        Book book = new Book("클린 코드", "로버트 C. 마틴", isbn);
        
        when(bookRepository.findByIsbn(isbn))
            .thenReturn(Optional.of(book));
        
        // When
        bookService.rentBook(isbn, userId);
        
        // Then
        assertTrue(book.isRented());
        verify(bookRepository).save(book);
    }
}

🏗️ 통합 테스트 vs 단위 테스트

TDD를 하다 보면 단위 테스트와 통합 테스트를 구분해야 할 때가 있어.

단위 테스트 (Unit Test)
- 하나의 클래스나 메서드만 테스트
- 외부 의존성은 모두 모킹
- 빠르게 실행됨
- 개발 중에 자주 실행

통합 테스트 (Integration Test)
- 여러 컴포넌트가 함께 동작하는지 테스트
- 실제 데이터베이스, 외부 API 사용
- 실행 시간이 오래 걸림
- 배포 전에 실행

Spring Boot를 사용한다면 통합 테스트는 이렇게 작성할 수 있어:

@SpringBootTest
@AutoConfigureTestDatabase
class BookServiceIntegrationTest {
    
    @Autowired
    private BookService bookService;
    
    @Autowired
    private BookRepository bookRepository;
    
    @BeforeEach
    void setUp() {
        bookRepository.deleteAll();
    }
    
    @Test
    @DisplayName("책 추가 통합 테스트")
    void testAddBook_Integration() {
        // Given
        String title = "클린 아키텍처";
        String author = "로버트 C. 마틴";
        String isbn = "978-8966262472";
        
        // When
        Book book = bookService.addBook(title, author, isbn);
        
        // Then
        assertNotNull(book);
        
        // 실제로 DB에 저장되었는지 확인
        Optional<Book> found = bookRepository.findByIsbn(isbn);
        assertTrue(found.isPresent());
        assertEquals(title, found.get().getTitle());
    }
}

💎 TDD 베스트 프랙티스

TDD를 효과적으로 사용하려면 몇 가지 원칙을 지키는 게 좋아. 실전 경험을 바탕으로 정리한 베스트 프랙티스를 공유할게! 🌟

1️⃣ 테스트는 작고 빠르게

2️⃣ 의미 있는 테스트 이름

테스트 이름만 봐도 무엇을 테스트하는지 알 수 있어야 해. 좋은 예와 나쁜 예를 비교해볼까?

// ❌ 나쁜 예
@Test
void test1() { }

@Test
void testAdd() { }

// ✅ 좋은 예
@Test
@DisplayName("양수 두 개를 더하면 올바른 합을 반환한다")
void shouldReturnCorrectSum_WhenAddingTwoPositiveNumbers() { }

@Test
@DisplayName("0으로 나누면 ArithmeticException이 발생한다")
void shouldThrowArithmeticException_WhenDividingByZero() { }

3️⃣ AAA 패턴 (Arrange-Act-Assert)

테스트 코드를 세 부분으로 명확히 구분하면 가독성이 좋아져.

@Test
void testUserRegistration() {
    // Arrange (준비): 테스트에 필요한 데이터와 상태 설정
    String email = "test@example.com";
    String password = "password123";
    UserService userService = new UserService(mockRepository);
    
    // Act (실행): 테스트할 동작 수행
    User user = userService.register(email, password);
    
    // Assert (검증): 결과 확인
    assertNotNull(user);
    assertEquals(email, user.getEmail());
    assertTrue(user.isActive());
}

4️⃣ 하나의 테스트는 하나의 개념만

한 테스트에서 너무 많은 걸 검증하려고 하지 마. 테스트가 실패했을 때 원인을 찾기 어려워져.

// ❌ 나쁜 예: 여러 개념을 한 번에 테스트
@Test
void testUserOperations() {
    User user = userService.register("test@example.com", "pass");
    assertNotNull(user);
    
    user.setName("홍길동");
    userService.update(user);
    assertEquals("홍길동", user.getName());
    
    userService.delete(user.getId());
    assertFalse(userService.exists(user.getId()));
}

// ✅ 좋은 예: 각 개념을 별도로 테스트
@Test
void testUserRegistration() {
    User user = userService.register("test@example.com", "pass");
    assertNotNull(user);
}

@Test
void testUserUpdate() {
    User user = createTestUser();
    user.setName("홍길동");
    userService.update(user);
    assertEquals("홍길동", user.getName());
}

@Test
void testUserDeletion() {
    User user = createTestUser();
    userService.delete(user.getId());
    assertFalse(userService.exists(user.getId()));
}

5️⃣ 테스트 데이터 관리

테스트 데이터를 효율적으로 관리하는 방법들이 있어:

// Test Fixture 패턴
public class TestFixtures {
    public static User createTestUser() {
        return new User("test@example.com", "password", "테스트유저");
    }
    
    public static User createTestUser(String email) {
        return new User(email, "password", "테스트유저");
    }
    
    public static Book createTestBook() {
        return new Book("테스트 책", "테스트 저자", "123-456");
    }
}

// Builder 패턴
public class UserBuilder {
    private String email = "test@example.com";
    private String password = "password";
    private String name = "테스트";
    private boolean active = true;
    
    public UserBuilder email(String email) {
        this.email = email;
        return this;
    }
    
    public UserBuilder password(String password) {
        this.password = password;
        return this;
    }
    
    public UserBuilder inactive() {
        this.active = false;
        return this;
    }
    
    public User build() {
        User user = new User(email, password, name);
        user.setActive(active);
        return user;
    }
}

// 사용 예
@Test
void testInactiveUser() {
    User user = new UserBuilder()
        .email("inactive@example.com")
        .inactive()
        .build();
    
    assertFalse(user.isActive());
}

6️⃣ 테스트 커버리지의 함정

많은 팀이 "테스트 커버리지 80% 이상"같은 목표를 세워. 하지만 커버리지가 높다고 해서 좋은 테스트는 아니야! 😅

중요한 건 의미 있는 테스트야:
✅ 비즈니스 로직을 제대로 검증하는가?
✅ 엣지 케이스를 다루는가?
✅ 예외 상황을 테스트하는가?
✅ 테스트가 실패하면 실제 문제를 찾을 수 있는가?

단순히 커버리지를 높이기 위한 테스트는 오히려 유지보수 부담만 늘려.

7️⃣ 리팩토링과 테스트

TDD의 마지막 단계인 리팩토링은 정말 중요해. 테스트가 있으니까 안심하고 코드를 개선할 수 있어!

// 리팩토링 전
public class OrderService {
    public double calculateTotal(Order order) {
        double total = 0;
        for (OrderItem item : order.getItems()) {
            total += item.getPrice() * item.getQuantity();
        }
        if (order.getCustomer().isPremium()) {
            total = total * 0.9; // 10% 할인
        }
        if (total > 100000) {
            total = total * 0.95; // 5% 추가 할인
        }
        return total;
    }
}

// 리팩토링 후
public class OrderService {
    private static final double PREMIUM_DISCOUNT = 0.9;
    private static final double BULK_DISCOUNT = 0.95;
    private static final double BULK_THRESHOLD = 100000;
    
    public double calculateTotal(Order order) {
        double subtotal = calculateSubtotal(order);
        double afterPremiumDiscount = applyPremiumDiscount(subtotal, order);
        return applyBulkDiscount(afterPremiumDiscount);
    }
    
    private double calculateSubtotal(Order order) {
        return order.getItems().stream()
            .mapToDouble(item -> item.getPrice() * item.getQuantity())
            .sum();
    }
    
    private double applyPremiumDiscount(double amount, Order order) {
        return order.getCustomer().isPremium() 
            ? amount * PREMIUM_DISCOUNT 
            : amount;
    }
    
    private double applyBulkDiscount(double amount) {
        return amount > BULK_THRESHOLD 
            ? amount * BULK_DISCOUNT 
            : amount;
    }
}

리팩토링 후에도 모든 테스트가 통과하면, 코드가 여전히 올바르게 동작한다는 확신을 가질 수 있어! 🎉

🚧 TDD의 현실적인 어려움과 해결책

솔직히 말할게. TDD는 이상적으로는 완벽하지만, 현실에서는 여러 어려움이 있어. 하지만 이런 문제들을 인식하고 대처하면 충분히 극복할 수 있어! 💪

😰 어려움 1: 시간 압박

문제: "테스트 코드 짤 시간이 어디 있어요? 기능 구현도 바쁜데!"

해결책:
- 처음에는 시간이 더 걸리는 게 맞아. 하지만 장기적으로는 디버깅 시간이 줄어들어서 오히려 빨라져.
- 모든 코드에 TDD를 적용하려고 하지 마. 중요한 비즈니스 로직부터 시작해.
- 팀 전체가 TDD에 익숙해지면 개발 속도가 점점 빨라져.
- 매니저나 팀장에게 TDD의 장기적 이점을 설명하고 이해를 구해.

😵 어려움 2: 레거시 코드

문제: "이미 만들어진 코드가 산더미인데 어떻게 TDD를 해요?"

해결책:
- 새로운 기능은 TDD로 개발해.
- 버그를 수정할 때, 먼저 버그를 재현하는 테스트를 작성해.
- 리팩토링할 때 점진적으로 테스트를 추가해.
- "Characterization Tests"를 작성해서 기존 코드의 동작을 문서화해.

// 레거시 코드의 동작을 테스트로 문서화
@Test
void characterizeExistingBehavior() {
    // 기존 코드가 어떻게 동작하는지 테스트로 기록
    LegacyService service = new LegacyService();
    String result = service.doSomething("input");
    
    // 현재 동작을 assert로 고정
    assertEquals("expected output", result);
    // 이제 리팩토링해도 동작이 변하지 않았는지 확인 가능!
}

🤯 어려움 3: 테스트하기 어려운 코드

문제: "이 코드는 테스트가 불가능해요!"

해결책:
대부분의 경우 "테스트하기 어려운 코드"는 "설계가 좋지 않은 코드"야. TDD는 자연스럽게 더 나은 설계로 이끌어줘.

// ❌ 테스트하기 어려운 코드
public class UserService {
    public void registerUser(String email, String password) {
        // 직접 DB에 연결
        Connection conn = DriverManager.getConnection("jdbc:mysql://...");
        // 직접 이메일 발송
        EmailSender.send(email, "Welcome!");
        // 현재 시간 직접 사용
        user.setCreatedAt(new Date());
    }
}

// ✅ 테스트하기 쉬운 코드
public class UserService {
    private UserRepository repository;
    private EmailService emailService;
    private Clock clock;
    
    public UserService(UserRepository repository, 
                      EmailService emailService,
                      Clock clock) {
        this.repository = repository;
        this.emailService = emailService;
        this.clock = clock;
    }
    
    public void registerUser(String email, String password) {
        User user = new User(email, password);
        user.setCreatedAt(clock.now());
        repository.save(user);
        emailService.sendWelcomeEmail(email);
    }
}

😤 어려움 4: 팀원들의 저항

문제: "팀원들이 TDD를 하기 싫어해요."

해결책:
- 강요하지 말고 먼저 본인이 실천해서 효과를 보여줘.
- 페어 프로그래밍으로 함께 TDD를 경험해봐.
- 작은 성공 사례를 공유해.
- TDD 스터디나 코드 리뷰를 통해 자연스럽게 학습 기회를 만들어.
- 완벽한 TDD가 아니어도 괜찮아. 점진적으로 개선해 나가면 돼.

🎯 어려움 5: 무엇을 테스트해야 할지 모르겠어요

문제: "테스트를 작성하고 싶은데 어디서부터 시작해야 할지 막막해요."

해결책:
이런 순서로 생각해봐:

// 계산기 예제로 보는 테스트 우선순위

// 1. Happy Path
@Test
void shouldAdd_WhenGivenTwoPositiveNumbers() {
    assertEquals(5, calculator.add(2, 3));
}

// 2. Edge Cases
@Test
void shouldHandleZero() {
    assertEquals(0, calculator.add(0, 0));
    assertEquals(5, calculator.add(5, 0));
}

@Test
void shouldHandleNegativeNumbers() {
    assertEquals(-5, calculator.add(-2, -3));
    assertEquals(1, calculator.add(-2, 3));
}

// 3. Error Cases
@Test
void shouldThrowException_WhenResultOverflows() {
    assertThrows(ArithmeticException.class, () -> {
        calculator.add(Integer.MAX_VALUE, 1);
    });
}

// 4. Business Rules
@Test
void shouldRoundResult_WhenDividing() {
    // 비즈니스 규칙: 나눗셈 결과는 소수점 둘째자리에서 반올림
    assertEquals(3.33, calculator.divide(10, 3), 0.01);
}

🎓 실무에서 배운 TDD 팁들

여러 프로젝트를 거치면서 배운 실용적인 팁들을 공유할게. 책에서는 잘 안 나오는 현장의 노하우들이야! 😎

💡 Tip 1: 테스트 이름에 한글 사용하기

영어로 테스트 이름을 짓다 보면 길어지고 복잡해져. 한글을 사용하면 훨씬 명확해!

// 영어
@Test
void shouldThrowInvalidEmailExceptionWhenEmailFormatIsInvalid() { }

// 한글
@Test
@DisplayName("이메일 형식이 잘못되면 InvalidEmailException이 발생한다")
void 이메일_형식_검증() { }

💡 Tip 2: 테스트 실행 순서에 의존하지 않기

각 테스트는 독립적으로 실행되어야 해. 다른 테스트의 결과에 의존하면 안 돼!

// ❌ 나쁜 예: 테스트 순서에 의존
private static User savedUser;

@Test
void test1_saveUser() {
    savedUser = userService.save(new User("test@example.com"));
}

@Test
void test2_findUser() {
    User found = userService.findById(savedUser.getId());
    assertNotNull(found);
}

// ✅ 좋은 예: 각 테스트가 독립적
@Test
void testSaveUser() {
    User user = userService.save(new User("test@example.com"));
    assertNotNull(user.getId());
}

@Test
void testFindUser() {
    User user = userService.save(new User("test@example.com"));
    User found = userService.findById(user.getId());
    assertNotNull(found);
}

💡 Tip 3: 테스트 데이터는 명확하게

테스트에서 사용하는 데이터는 의미가 명확해야 해. "test1", "abc" 같은 의미 없는 값 대신 실제 같은 데이터를 사용해.

// ❌ 의미 없는 테스트 데이터
@Test
void test() {
    User user = new User("a", "b", 1);
    // 이게 뭘 테스트하는 건지 알기 어려워
}

// ✅ 의미 있는 테스트 데이터
@Test
void 미성년자는_성인_콘텐츠를_볼_수_없다() {
    User minorUser = new User("김철수", "minor@example.com", 15);
    Content adultContent = new Content("성인 영화", Rating.ADULT);
    
    assertFalse(contentService.canView(minorUser, adultContent));
}

💡 Tip 4: 테스트 코드도 리팩토링하기

테스트 코드도 프로덕션 코드만큼 중요해. 중복을 제거하고 가독성을 높여야 해!

// 공통 설정을 헬퍼 메서드로 추출
class OrderServiceTest {
    
    private Order createTestOrder() {
        Order order = new Order();
        order.addItem(new OrderItem("상품1", 10000, 2));
        order.addItem(new OrderItem("상품2", 20000, 1));
        return order;
    }
    
    private User createPremiumUser() {
        User user = new User("premium@example.com");
        user.setPremium(true);
        return user;
    }
    
    @Test
    void 프리미엄_회원은_10퍼센트_할인() {
        Order order = createTestOrder();
        User user = createPremiumUser();
        order.setCustomer(user);
        
        double total = orderService.calculateTotal(order);
        assertEquals(36000, total); // (10000*2 + 20000) * 0.9
    }
}

💡 Tip 5: 실패 메시지를 명확하게

테스트가 실패했을 때 원인을 빠르게 파악할 수 있도록 명확한 메시지를 작성해.

// ❌ 불명확한 실패 메시지
assertEquals(expected, actual);

// ✅ 명확한 실패 메시지
assertEquals(expected, actual, 
    String.format("주문 총액이 예상과 다릅니다. 예상: %d, 실제: %d", expected, actual));

// 더 나은 방법: assertJ 같은 라이브러리 사용
assertThat(actual)
    .as("주문 총액 검증")
    .isEqualTo(expected);

💡 Tip 6: 플래키 테스트(Flaky Test) 주의

가끔 성공하고 가끔 실패하는 테스트를 플래키 테스트라고 해. 이런 테스트는 정말 골치 아파!

플래키 테스트의 주요 원인:
- 시간에 의존하는 코드
- 랜덤 값 사용
- 외부 시스템 의존
- 병렬 실행 시 공유 자원 접근
- 테스트 순서 의존성

// ❌ 플래키 테스트
@Test
void testTimeout() {
    long start = System.currentTimeMillis();
    service.doSomething();
    long end = System.currentTimeMillis();
    
    // 실행 시간이 시스템 상태에 따라 달라질 수 있어
    assertTrue(end - start < 1000);
}

// ✅ 개선된 테스트
@Test
@Timeout(value = 1, unit = TimeUnit.SECONDS)
void testTimeout() {
    service.doSomething();
    // JUnit의 @Timeout 사용
}

🌐 재능넷에서 TDD 전문가 찾기

TDD와 테스팅 프레임워크를 혼자 공부하다 보면 막히는 부분이 있을 수 있어. 그럴 때는 전문가의 도움을 받는 것도 좋은 방법이야! 🎓

재능넷에서는 다양한 프로그래밍 전문가들이 활동하고 있어. TDD 코칭, 코드 리뷰, 테스트 코드 작성 컨설팅 등 실무에 바로 적용할 수 있는 실전 노하우를 배울 수 있지. 특히 실제 프로젝트에 TDD를 도입하려고 할 때, 경험 있는 멘토의 조언이 큰 도움이 될 거야.

혼자 고민하지 말고 재능넷에서 당신에게 맞는 전문가를 찾아보는 건 어때? 때로는 한 시간의 멘토링이 며칠간의 삽질을 줄여줄 수 있거든! 😊

🎬 마무리하며

와, 여기까지 정말 긴 여정이었어! JUnit, TestNG, Mockito 같은 테스팅 프레임워크부터 TDD 방법론까지 함께 살펴봤어. 🎉

처음에는 TDD가 어렵고 시간이 많이 걸리는 것처럼 느껴질 수 있어. 하지만 계속 연습하다 보면 자연스러워지고, 어느새 테스트 없이는 코드를 짤 수 없게 될 거야. 나도 그랬거든! 😄

기억해야 할 핵심 포인트들:

🎯 TDD는 단순히 테스트 작성이 아니야
설계를 개선하고, 코드 품질을 높이고, 개발자의 자신감을 키워주는 개발 방법론이야.

🎯 완벽을 추구하지 마
모든 코드에 100% 테스트 커버리지를 달성하려고 하지 마. 중요한 비즈니스 로직부터 시작해서 점진적으로 개선해 나가면 돼.

🎯 도구는 수단일 뿐이야
JUnit이든 TestNG든, 어떤 프레임워크를 쓰는지는 중요하지 않아. 중요한 건 테스트를 통해 코드 품질을 높이는 거야.

🎯 팀과 함께 성장하자
혼자만 TDD를 하면 힘들어. 팀원들과 함께 학습하고, 경험을 공유하고, 서로 도와가며 성장하자.

🎯 실패를 두려워하지 마
테스트가 실패하는 건 나쁜 게 아니야. 오히려 문제를 일찍 발견한 거니까 좋은 거지! Red-Green-Refactor 사이클을 즐겨봐.

TDD는 마라톤이야. 단거리 달리기가 아니지. 천천히, 꾸준히 연습하다 보면 어느새 당신도 TDD 마스터가 되어 있을 거야! 💪

이 글이 당신의 TDD 여정에 도움이 되었으면 좋겠어. 궁금한 점이 있거나 더 깊이 배우고 싶다면, 재능넷에서 전문가들과 함께 성장해보는 것도 추천해! 🚀

자, 이제 에디터를 열고 첫 번째 테스트를 작성해볼까? 화이팅! 🎊