🤖 AN 테스트 전략

🔈 Test

UI Test: Espresso, Unit Test: Kotest, Mock: Mockk

Unit Test 컨벤션

BDD 기법 중 Given-When-Then 패턴을 사용하여 작성한다.

1. given: 시나리오 진행에 필요한 데이터 준비
2. when: 시나리오를 진행하는데 필요 조건
3. then: 시나리오를 완료했을 때 보장해야 하는 결과

@Test
fun `test`() {
    // given
    val num1 = 1
    val num2 = 2
    // when
    val actual = sum(num1, num2)
    // then
    val expect = 3
    actual shouldBe expect
}

• ViewModel Test 는 반드시 구현해야 한다.
• 그 외의 Test는 작성자가 선택적으로 테스트한다.
• 성공 시나리오는 **반드시 Fake 객체**를 사용하여 테스트한다.
• 예외 시나리오의 경우는 Mock을 활용하여 테스트해도 된다.

Fake 객체를 사용하는 이유

Android Test

• Product용 Repository 가 아닌 Fake Repository를 사용한다.
• Fake를 사용하기 어려울 경우에만 Mock 을 사용하여 테스트한다.
• 화면별 Portrait, Landscape 테스트는 필수다.

Fake 객체를 사용하는 이유

1. 실제 동작과 유사한 동작을 하기에 신뢰성 있는 테스트를 제공
2. Unit Test 와 Android Test 에서 재사용될 수 있음

Fake 객체는 testing 모듈 에 모아두었습니다.

Fake 객체와 Mock 객체 비교

구분	Fake 객체	Mock 객체
정의	Product 객체를 모방한 객체로, 실제 동작을 단순화한 구현체	특정 행동이 일어났는지 검증하기 위한 객체로, 예상된 호출과 응답을 미리 정의
주용도	실제 동작을 모방하여 테스트의 충실도와 신뢰성을 높임	행동 검증 (Behavior Verification)
장점	- 높은 테스트 충실도 - 다양한 테스트 환경에서 재사용 가능 - 객체의 내부 코드를 신경 쓰지 않고 사용 가능 (추상화, 캡슐화)	- 테스트 시 호출된 메서드와 그 순서를 검증 가능 - 테스트 케이스가 명확하고 구체적임
단점	- 프로덕트 코드가 변경되면 Fake도 변경되어야 함 (유지보수 비용 증가) - Fake도 실제처럼 동작하는지 테스트 필요	- 예상된 호출과 응답을 미리 정의해야 하므로 설정이 번거로움 - 테스트가 Mock 객체에 의존하게 되어 유연성이 떨어질 수 있음
사용 사례	- DB나 Server 와의 의존성을 제거하고 독립적인 ViewModel 테스트 수행	- 특정 메서드가 호출되었는지 검증이 필요한 경우