🤖 AN 테스트 전략

🔈 Test

• Instrumentation Test: Espresso.
• Integration Test: Robelectric
• Unit Test: Kotest.
• Test Double: Fake, 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 객체를 사용하는 이유

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

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

Fake 객체와 Mock 객체 비교

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

Android Test

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

Room Migration Test

테스트 작성 방법 https://github.com/woowacourse-teams/2024-pokerogue-helper/pull/434 참고

디비 마이그레이션 테스트에 대한 이해를 위해 간단하게 작성해둘게여 테스트 코드를 작성하는 방법은 작성한 코드를 봐주세여~

room-test에서 지원하는 MigrationTestHelper 가 scheme history를 기반으로 마이그레이션 테스트합니다. 따라서, androidTest/schemas/../pokeRogueDatabase/(dbVersion).json 에 이전 디비 버전의 scheme 들이 있어야합니다.

그리고, 마이그레이션 테스트에는 다음과 같이 2가지 종류의 테스트가 있다고 합니다.

1) 단일 마이그레이션 테스트 (데이터 무결성 테스트)

DB 버전을 올려도 이전 데이터가 손상이 일어나지 않는지를 테스트합니다!

// from: db version 1
data class User(
   @PrimaryKey val id: String,
    val name: String,
)

// to: db version 2

data class User(
   @PrimaryKey val id: String,
    val name: String,
    @ColumnInfo(defaultValue = -1)    
    val age: Int,
)

위와 같이 User 에 age 라는 새로운 컬럼이 추가되었으면 2가지 테스트를 합니다.

1. 기존 데이터가 손상되었는가?
2. 새로운 컬럼에 default 값이 들어가는가

2) 전체 마이그레이션 테스트

가장 오래된 db 버전이 1이고, 가장 최신 db 버전이 10이라고 가정했을 때
1 에서 10으로 마이그레이션하는데 문제가 없는지 확인하는 테스트입니다!

DB Migration 테스트

디비 마이그레이션 테스트에 대한 이해를 위해 간단하게 작성해둘게여 테스트 코드를 작성하는 방법은 작성한 코드를 봐주세여~

room-test에서 지원하는 MigrationTestHelper 가 scheme history를 기반으로 마이그레이션 테스트합니다. 따라서, androidTest/schemas/../pokeRogueDatabase/(dbVersion).json 에 이전 디비 버전의 scheme 들이 있어야합니다.

그리고, 마이그레이션 테스트에는 다음과 같이 2가지 종류의 테스트가 있다고 합니다.

1) 단일 마이그레이션 테스트 (데이터 무결성 테스트)

DB 버전을 올려도 이전 데이터가 손상이 일어나지 않는지를 테스트합니다!

// from: db version 1
data class User(
   @PrimaryKey val id: String,
    val name: String,
)

// to: db version 2

data class User(
   @PrimaryKey val id: String,
    val name: String,
    @ColumnInfo(defaultValue = -1)    
    val age: Int,
)

위와 같이 User 에 age 라는 새로운 컬럼이 추가되었으면 2가지 테스트를 합니다.

1. 기존 데이터가 손상되었는가?
2. 새로운 컬럼에 default 값이 들어가는가

2) 전체 마이그레이션 테스트

가장 오래된 db 버전이 1이고, 가장 최신 db 버전이 10이라고 가정했을 때
1 에서 10으로 마이그레이션하는데 문제가 없는지 확인하는 테스트입니다!