Androidアプリ開発の覚書き

Androidアプリ開発を、Kotlin, Jetpack Composeで行っています。気になったことをChatGPTに聞いて記事にしています。

Kotlin, Androidのテストの基本(2)

テスト

Matcherクラス、Mockオブジェクト、各テストの前後の処理を記述するRuleについて、簡単に聞いてみました。

JUnit4で使えるMatcherについて教えてください。

User
JUnit4で使えるMatcherについて教えてください。

ChatGPT
JUnit4で利用可能なMatcherクラスは、主にorg.hamcrestパッケージに含まれています。これらのMatcherは、テストのアサーションをより読みやすく、記述的に行うために用いられます。以下に一般的なMatcherの種類をいくつか紹介します：

○Core Matchers:
is: 値が特定の条件に一致するかを検証します。

not: 条件を否定します。

equalTo: ある値が他の値と等しいかを検証します。

instanceOf: 指定されたクラスのインスタンスであるかを検証します。

○Collection Matchers:
hasItems: コレクションが特定の要素を含むことを検証します。

hasSize: コレクションのサイズが特定の値であることを検証します。

isEmpty: コレクションが空であることを検証します。

○Text Matchers:
equalToIgnoringCase: 文字列が、大文字小文字を無視して同じかどうかを検証します。

equalToIgnoringWhiteSpace: 文字列が、空白を無視して同じかどうかを検証します。

stringContainsInOrder: 文字列が特定の部分文字列を含む順序であることを検証します。

これらのMatcherを使用するには、通常、assertThatメソッドと組み合わせて使用します。例えば、数値が10であること、文字列が期待する値と等しいこと、そしてリストが特定の要素を含むことを検証するテスト例を示します：

import org.junit.Test  
import org.hamcrest.MatcherAssert.assertThat  
import org.hamcrest.Matchers.*  
  
class ExampleUnitTest {  
  @Test  
  fun testNumber() {  
    val number = 10  
    assertThat(number, `is`(equalTo(10)))  
  }  
  
  @Test  
  fun testString() {  
    val string = "Hello, World!"  
    assertThat(string, `is`(equalTo("Hello, World!")))  
  }  
  
  @Test  
  fun testList() {  
    val list = listOf("apple", "banana", "orange")  
    assertThat(list, hasItems("banana", "orange"))  
  }  
}

このコード例では以下のことを行っています：
testNumber: 数値が10と等しいことを検証しています。

testString: 文字列が"Hello, World!"と等しいことを検証しています。

testList: リストが"banana"と"orange"を含んでいることを検証しています。

これらのテストは、それぞれの条件を直感的に理解しやすい形で表現しており、JUnitとHamcrestのMatcherを組み合わせることで、より柔軟で強力なテストケースを作成することができます。

正しい例外が発生するかどうかの検証はできますか？

User
正しい例外が発生するかどうかの検証はできますか？

ChatGPT
はい、KotlinとJUnitで正しい例外が発生するかどうかを検証する方法がいくつかあります。JUnit4を使う場合、主に以下の方法で例外の検証を行うことができます。

1. expected 属性を使用する
@Test アノテーションの expected 属性を使用して、特定の例外がテスト中に投げられることを期待するように指定します。例えば、ある関数が IllegalArgumentException を投げることを期待するテストは以下のようになります：

import org.junit.Test  
  
class ExampleExceptionTest {  
  @Test(expected = IllegalArgumentException::class)  
  fun testException() {  
    // この関数がIllegalArgumentExceptionを投げることを期待  
    functionThatThrowsException()  
  }  
  
  fun functionThatThrowsException() {  
    throw IllegalArgumentException("Invalid argument")  
  }  
}

2. try-catch ブロックを使用する
例外の種類だけでなく、例外メッセージなどの追加的な検証を行いたい場合は、try-catch ブロック内でテストを書き、assert を使用して検証します：

import org.junit.Test  
import kotlin.test.assertEquals  
import kotlin.test.fail  
  
class ExampleExceptionTest {  
  @Test  
  fun testExceptionDetails() {  
    try {  
      functionThatThrowsException()  
      fail("Expected an IllegalArgumentException to be thrown")  
    } catch (e: IllegalArgumentException) {  
      assertEquals("Invalid argument", e.message)  
    }  
  }  
  
  fun functionThatThrowsException() {  
    throw IllegalArgumentException("Invalid argument")  
  }  
}

この方法では、fail() 関数を使って例外が投げられなかった場合にテストが失敗するように設定し、catch ブロック内で例外の種類やメッセージを検証しています。

これらの方法を使用して、期待される例外が適切に発生しているかどうかを検証することができます。

@Testアノテーションで指定できるテストが他にもあれば教えてください。

User
@Testアノテーションで指定できるテストが他にもあれば教えてください。

ChatGPT
JUnit4の@Testアノテーションを使用する際に指定できるいくつかの重要な属性があります。これらはテストの書き方や実行時の振る舞いをカスタマイズするのに役立ちます。

1. expected
すでに説明したように、expected属性は指定されたタイプの例外がテストメソッド実行時に投げられることを期待します。この属性が設定されている場合、指定した例外が投げられなければテストは失敗します。

2. timeout
timeout属性は、テストが指定された時間内に完了することを保証します。この時間はミリ秒単位で指定します。もしテストがこの時間を超えてしまった場合、JUnitはテストを失敗とみなします。これは、特にパフォーマンスをチェックするテストや、デッドロックに陥りがちなコードをテストする際に有用です。

例えば、5秒以内に完了することが期待されるテストは次のように書けます：

import org.junit.Test  
  
class ExampleTimeoutTest {  
  @Test(timeout = 5000) // 5000 milliseconds = 5 seconds  
  fun testWithTimeout() {  
    // ここに時間がかかるかもしれない処理を記述  
  }  
}

使用例
例外とタイムアウトの設定を組み合わせた例を示します：

import org.junit.Test  
  
class ExampleTest {  
  @Test(expected = IllegalArgumentException::class, timeout = 1000)  
  fun testExceptionWithTimeout() {  
    // この関数が1秒以内にIllegalArgumentExceptionを投げることを期待  
    functionThatThrowsException()  
  }  
  
  fun functionThatThrowsException() {  
    Thread.sleep(500) // 0.5秒待機  
    throw IllegalArgumentException("This is a test exception")  
  }  
}

この例では、functionThatThrowsExceptionが500ミリ秒待ってからIllegalArgumentExceptionを投げます。@Testアノテーションは例外が正しいタイプであり、かつ1秒以内に投げられることを期待しています。

これらの属性を利用することで、JUnitを使ったテストの表現力を高め、より効果的にテストケースを管理できます。

テストケースはpublicメソッドについてすると聞いたことがあります。この点について教えてください。

User
テストケースはpublicメソッドについてすると聞いたことがあります。この点について教えてください。

ChatGPT
JUnitを用いたテストでは、テスト対象のメソッドの可視性について一般的なルールがあります。テストは通常、publicメソッドを対象に行われるとされていますが、その理由や背景にはいくつかの要素が関わっています。

○テストの焦点
Publicメソッド:
Publicメソッドはクラスの外部インターフェイスを形成します。つまり、クラスの機能を外部のコードからアクセスできる部分です。

このため、publicメソッドは直接的な使用ケースや振る舞いをテストすることが多いです。テストを通じて、それらのメソッドが期待される動作を正確に行うかを確認します。

Privateメソッド:
Privateメソッドはクラスの内部実装の一部であり、クラスの外からは直接アクセスすることができません。

一般的に、privateメソッドは直接テストするのではなく、publicメソッドを通じて間接的にテストされます。これは、内部メソッドの振る舞いが外部にどのように影響するかを見ることで、内部の正確性を確認することができるからです。

○ユニットテストの原則
カプセル化の維持:
オブジェクト指向プログラミングの原則において、カプセル化は非常に重要です。テストを行う際にprivateメソッドや内部状態に直接アクセスすることは、カプセル化を侵害する行為になり得ます。

Publicメソッドをテストすることで、クラスのカプセル化を保持し、外部からの利用者が直面するであろうシナリオを模倣します。

テストの独立性:
テストは他のテストに依存せずに独立して実行可能であるべきです。Privateメソッドを直接テストする場合、そのメソッドが変更されると、テスト自体も変更しなければならないことがよくあります。

Publicメソッドのテストは、実装の詳細（どのprivateメソッドがどのように使われているか）から抽象化されており、内部の変更があってもテストの変更が不要になることが多いです。

○実践
実際にテストを書く際には、そのクラスがどのように使われるかを考慮して、最も重要な振る舞いやメソッドに焦点を当てることが推奨されます。これにより、保守が容易で、可読性が高く、信頼性の高いテストを作成することができます。また、リファクタリングが必要な場合にも、publicインターフェイスが変わらない限り、テストをそのまま保持できるため、改修の際の安心感が得られます。

ありがとうございます。Androidの環境なのですが、Mockオブジェクトを利用したテストについても教えてください。

User
ありがとうございます。

Androidの環境なのですが、Mockオブジェクトを利用したテストについても教えてください。

ChatGPT
Android開発において、Mockオブジェクトを使用したテストは非常に一般的で、特にUIが絡むテストやAPI通信を模倣する場合に役立ちます。Mockオブジェクトは、テスト対象のコードに依存する他の部分をシミュレートし、テストの際に必要なコントロールや予測可能な結果を提供します。

○Mockオブジェクトの利用
Mockオブジェクトを利用する主な理由は以下の通りです：
依存関係の分離:
実際のオブジェクトの代わりにMockオブジェクトを用いることで、外部システムや未実装の機能に依存しないテストが可能になります。

環境の簡素化:
特にAPIサーバーやデータベースとの通信を必要とする場合、これらをMock化することでテスト環境を簡素化し、テストの速度を向上させることができます。

振る舞いの制御:
Mockオブジェクトを使用することで、特定のテストケースで想定される特定の振る舞いやエラーケースを再現しやすくなります。

○AndroidでのMockオブジェクトの実装
Androidプロジェクトでは、MockitoやMockK（Kotlin用のMockライブラリ）がよく使われます。以下に、Mockitoを使った基本的なMockオブジェクトの利用方法を示します。

依存関係の追加
まずは、build.gradle（appレベル）に以下の依存関係を追加します：

dependencies {  
  testImplementation 'org.mockito:mockito-core:3.x'  
  androidTestImplementation 'org.mockito:mockito-android:3.x'  
}

テストの例
次に、サービスクラスのMockを作成し、そのサービスを利用するクラスをテストします。ここでは、UserProfileFetcherクラスが依存するUserServiceをMock化します。

import org.mockito.Mockito.*  
import org.junit.Test  
import org.junit.Before  
import org.mockito.Mock  
import org.mockito.MockitoAnnotations  
  
class UserProfileFetcherTest {  
  
  @Mock  
  lateinit var userService: UserService  
  
  lateinit var userProfileFetcher: UserProfileFetcher  
  
  @Before  
  fun setup() {  
    MockitoAnnotations.initMocks(this)  
    userProfileFetcher = UserProfileFetcher(userService)  
  }  
  
  @Test  
  fun fetchUserProfile_success() {  
    // Mockオブジェクトの設定  
    `when`(userService.getUserProfile(anyString())).thenReturn(UserProfile("Alice", "Developer"))  
  
    // メソッドの実行  
    val result = userProfileFetcher.fetchProfile("user123")  
  
    // 結果の検証  
    assertEquals("Alice", result.name)  
  }  
}

このテストでは、userService.getUserProfileメソッドの振る舞いをMock化して、特定の入力（ここではユーザID）に対して期待されるUserProfileオブジェクトを返すように設定しています。これにより、UserProfileFetcherが正しく依存オブジェクトを使用しているかどうかを検証できます。

Mockオブジェクトを使ったテストは、複雑な依存関係や外部システムの影響を受けずに、アプリケーションのロジックを効率的にテストする手段を提供します。

initMocksにthisを渡すのはなぜですか？

User
initMocksにthisを渡すのはなぜですか？

ChatGPT
initMocks(this)メソッドを呼び出してthisを渡す理由は、Mockitoが現在のテストクラスインスタンスに含まれるすべての@Mockアノテーションが付いたフィールドを初期化するためです。これにより、宣言されたそれぞれのMockフィールドにMockオブジェクトが割り当てられ、テストメソッド実行前に使用可能な状態になります。

使い方と背景
@Mockアノテーション: @Mockアノテーションは、クラスフィールドに適用され、そのフィールドがMockオブジェクトであることを示します。Mockitoはこれらのアノテーションが付いたフィールドを自動的にMockオブジェクトに置き換える必要があります。

initMocks(this)の役割: initMocks(this)を呼び出すと、Mockitoは引数として渡されたオブジェクト（この場合はテストクラス自身）をスキャンし、@Mockで注釈されたすべてのフィールドを特定し、それぞれに対応するMockオブジェクトを割り当てます。

コード例
以下の例では、UserServiceとUserRepositoryのMockオブジェクトをテストクラス内で宣言し、initMocks(this)を使用してこれらのフィールドを初期化しています。

import org.mockito.Mock  
import org.mockito.MockitoAnnotations  
import org.junit.Before  
import org.junit.Test  
import kotlin.test.assertEquals  
  
class UserServiceTest {  
  
  @Mock  
  lateinit var userRepository: UserRepository // Mockオブジェクトを宣言  
  
  lateinit var userService: UserService  
  
  @Before  
  fun setUp() {  
    MockitoAnnotations.initMocks(this) // Mockオブジェクトを初期化  
    userService = UserService(userRepository)  
  }  
  
  @Test  
  fun testGetUserById() {  
    val userId = "123"  
    `when`(userRepository.findById(userId)).thenReturn(User(userId, "Alice"))  
      
    val result = userService.getUserById(userId)  
      
    assertEquals("Alice", result.name)  
  }  
}

この例では、UserServiceが内部でuserRepositoryを使用しているため、userRepositoryをMock化することで、UserService.getUserByIdメソッドのテストを依存関係から隔離しています。

最新のMockitoとの互換性
なお、最新バージョンのMockitoではMockitoAnnotations.initMocks(this)の代わりにMockitoAnnotations.openMocks(this)を使用することが推奨されています。openMocksはリソースのリークを防ぐために、使用後にクローズする必要があります。通常はJUnitの@Afterアノテーションを使用したクリーンアップメソッド内で行います。

import org.mockito.MockitoAnnotations  
import org.junit.After  
import org.junit.Before  
  
class SomeTestClass {  
  private lateinit var closeable: AutoCloseable  
  
  @Before  
  fun setUp() {  
    closeable = MockitoAnnotations.openMocks(this)  
  }  
  
  @After  
  fun cleanUp() {  
    closeable.close()  
  }  
}

この新しいアプローチにより、テスト後にMockに関連するリソースが適切にクリーンアップされることが保証されます。

Before, Afterアノテーションの付いたメソッドをRuleで置き換えることはできますか？

User
Before, Afterアノテーションの付いたメソッドをRuleで置き換えることはできますか？

ChatGPT
はい、JUnit4では@Beforeや@Afterアノテーションで実行されるセットアップやクリーンアップのタスクをRuleを使って置き換えることができます。JUnitのRuleはテストメソッドの実行前後にコードを実行するためのより柔軟な方法を提供し、コードの再利用を促進し、テストクラスをより整理されたものにします。

Ruleの基本
JUnitのRuleは、テストの実行中に適用されるルールをカプセル化します。これには、リソースの管理、ログの作成、エラーの処理などが含まれることがあります。主なルールには以下のようなものがあります：

ExternalResource: テストメソッドの実行前後にリソースを設定・クリーンアップするためのベースクラスです。

ErrorCollector: テスト中にエラーを収集し、テストの最後にまとめて報告します。

TemporaryFolder: テスト中に使用する一時ファイルやディレクトリを管理します。

ExternalResourceの使用例
ExternalResourceは@Beforeや@Afterで実行される処理を置き換えるのに特に有用です。例えば、データベースのコネクションを開始し、テスト後にそれを閉じる必要がある場合、以下のようにRuleを利用できます：

import org.junit.Rule  
import org.junit.rules.ExternalResource  
  
class DatabaseTest {  
  @get:Rule  
  val database = object : ExternalResource() {  
    override fun before() {  
      // データベース接続を開始  
      startDatabase()  
    }  
  
    override fun after() {  
      // データベース接続を閉じる  
      closeDatabase()  
    }  
  
    fun startDatabase() {  
      // データベース開始のロジック  
    }  
  
    fun closeDatabase() {  
      // データベース終了のロジック  
    }  
  }  
  
  // テストメソッド  
}

このコードは、各テストメソッドの実行前にデータベースを開始し、実行後にそれを閉じることを保証します。Ruleを使用することで、同じリソース管理ロジックを多くのテストクラスで再利用することができ、テストコードの重複を減らすことができます。

テストの柔軟性向上
Ruleはテストクラス内で宣言され、そのクラス内のすべてのテストメソッドに適用されるため、テストの設定やクリーンアップ処理を一箇所に集中させることができます。これにより、テストの設計が柔軟になり、テストメソッドごとに異なる設定を簡単に適用することが可能になります。

クラススコープのRuleを作成することもできますか？

User
クラススコープのRuleを作成することもできますか？

ChatGPT
はい、JUnit4ではクラススコープで適用されるRuleを作成することが可能です。これはClassRuleアノテーションを使用して実現され、テストクラス全体にわたって一度だけ実行されるセットアップやクリーンアップ処理を定義するのに適しています。ClassRuleは、テストクラス内のすべてのテストメソッドの実行前後に一度ずつだけ実行されるルールです。

ClassRuleの利用例
例として、データベースの接続をテストクラスの全テストメソッドで共有する場合や、コストの高いリソースをテスト間で再利用する場合にClassRuleを利用することが考えられます。以下はその一例です：

import org.junit.ClassRule;  
import org.junit.rules.ExternalResource;  
import org.junit.Test;  
  
public class DatabaseConnectionTest {  
  @ClassRule  
  public static ExternalResource resource = new ExternalResource() {  
    @Override  
    protected void before() throws Throwable {  
      // テストクラス全体で使用するリソースを初期化  
      initializeDatabase();  
    }  
  
    @Override  
    protected void after() {  
      // テストクラス全体の終了後にリソースをクリーンアップ  
      shutdownDatabase();  
    }  
  
    private void initializeDatabase() {  
      System.out.println("Database initialized");  
    }  
  
    private void shutdownDatabase() {  
      System.out.println("Database shutdown");  
    }  
  };  
  
  @Test  
  public void test1() {  
    System.out.println("Test 1 is running");  
  }  
  
  @Test  
  public void test2() {  
    System.out.println("Test 2 is running");  
  }  
}

この例では、@ClassRuleを使用してデータベースの初期化とシャットダウンをテストクラスの開始前と全テスト終了後に一度ずつ行っています。これにより、テストメソッド間でデータベース接続を共有することが可能になり、テストの実行速度の向上やリソースの効率的な使用が期待できます。

注意点
@ClassRuleに指定するフィールドはstaticである必要があります。これは、クラスレベルで一度だけ実行されるため、インスタンスレベルのフィールドではなくクラスレベルのフィールドでなければならないためです。

@Ruleと@ClassRuleはそれぞれ異なる使用シナリオがあり、テストの設計に応じて適切に選択することが重要です。@Ruleは各テストメソッドの実行前後に処理が必要な場合に適しており、@ClassRuleはテストクラス全体で一度だけ必要な処理に適しています。

このように、JUnitのClassRuleはテストコードの整理とリソースの効率的な管理を助ける強力なツールです。

Kotlinだとどのような記述になりますか？

User
Kotlinだとどのような記述になりますか？

ChatGPT
KotlinでJUnit4の@ClassRuleを使用する場合、基本的な構成はJavaと似ていますが、Kotlin特有の記法がいくつか適用されます。以下は、Kotlinでデータベース接続の初期化とシャットダウンを行うClassRuleの実装例です。

KotlinでのClassRule実装例

import org.junit.ClassRule  
import org.junit.rules.ExternalResource  
import org.junit.Test  
  
class DatabaseConnectionTest {  
  companion object {  
    @JvmField  
    @ClassRule  
    val resource = object : ExternalResource() {  
      override fun before() {  
        // テストクラス全体で使用するリソースを初期化  
        initializeDatabase()  
      }  
  
      override fun after() {  
        // テストクラス全体の終了後にリソースをクリーンアップ  
        shutdownDatabase()  
      }  
  
      fun initializeDatabase() {  
        println("Database initialized")  
      }  
  
      fun shutdownDatabase() {  
        println("Database shutdown")  
      }  
    }  
  }  
  
  @Test  
  fun test1() {  
    println("Test 1 is running")  
  }  
  
  @Test  
  fun test2() {  
    println("Test 2 is running")  
  }  
}

主な違いとポイント
Companion Object: Kotlinではstaticメンバーを直接持つことができません。その代わりにcompanion objectブロックを使用してクラスレベルのフィールドやメソッドを定義します。

@JvmField アノテーション: @JvmFieldアノテーションは、KotlinプロパティがJavaのフィールドとして公開されるようにします。これはJUnitの@ClassRuleアノテーションがJavaのフィールドを期待するため必要です。このアノテーションによって、フィールドがpublic staticフィールドとして扱われ、JUnitから適切にアクセスされます。

オブジェクト式: Kotlinでは無名クラスのインスタンスを作成するためにオブジェクト式（object : SomeClass）を使用します。これはJavaの匿名クラスに似ています。

このように、KotlinでのJUnitテストではKotlinの機能を適切に利用しつつ、JUnitのルールに従う形でテスト環境を構築することができます。これにより、テストコードの可読性と保守性が向上します。

User
ありがとうございました。

ChatGPT
どういたしまして！また何か質問があればいつでもお気軽にどうぞ。お役に立てて嬉しいです！