devkuma – Testing

テスト概要

kc@example.com (kc kim) — Thu, 15 Sep 2022 20:08:00 +0900

テストの種類

単体テスト(Unit Test)

単体テストとは、クラスや関数単位で行うプログラムのテストである。主に設計どおりに動作するか、論理構造が適切かを確認する。

機能確認テスト
- 1つのモジュールが設計または仕様どおりに動作するかを確認するテスト
制御フローテスト
- プログラムの論理構造に従って、「命令」や「分岐」などが動作するかを確認するテスト
データフローテスト
- データや変数が「定義」「使用」「消滅」の順に実行されるかを確認するテスト

結合テスト(Integration Testing)

結合テストとは、単体テストで検証したプログラムを組み合わせて実行するテストである。

状態遷移テスト
- 状態遷移図に基づいて動作を確認するテスト

機能テスト

機能テストとは、結合したプログラムを1つの機能としてテストすることである。

機能確認テスト

システムテスト

システムテストは、個々のプログラムや機能を結合したプログラムが仕様書どおりに動作するかを検証するためのテストである。

確認テスト
- 回帰テスト
  - プログラム機能を修正または変更した後、変更された部分が正しく動作するかを確認するテスト
- デグレードテスト(Degrade test)
  - プログラム機能を追加または変更したことで、既存の機能が引き続き動作するかを確認するテスト
評価テスト
- セキュリティテスト(Security Test)
  - 悪意ある外部からの攻撃に対応できるか、脆弱性があるかを確認するテスト
- ユーザビリティテスト(Usability Test)
  - 視覚的に見やすく、ユーザーが操作、学習、理解しやすいかを確認するテスト
- 障害許容性テスト
  - 障害が発生した場合に指定された機能が維持されるかを確認するテスト
負荷テスト
- 性能テスト(Performance Test)
  - 処理能力が仕様書を満たしているかを確認するテスト
  - システムの要素が特定の状況でどの程度の性能を示すかを測定するテスト
- ロングランテスト
  - 長期間の連続稼働でも処理能力や稼働率に問題が発生しないかを確認するテスト
- 負荷テスト(Load Test)
  - 極端に高い負荷がかかる状況でも稼働できるかを確認するテスト
  - 特定の負荷を限られた時間だけ与え、Webアプリケーションに異常がないかを把握するテスト
- 持久テスト(Endurance Test)
  - Load Testと似ており、長期間負荷をかけて行うテスト。Agingテストともいう
- ストレステスト(Stress Test)
  - 負荷の限界点を見つけるために、段階的に負荷を上げながら進めるテスト
- ピーク負荷テスト(Peak Test)
  - 一瞬だけ耐えきれないほどの負荷を与え、Webアプリケーションが停止せず、正常に動作して回復するかを見るテスト

ユーザーテスト

受け入れテスト
- 対象システムがユーザーの要求を満たすかを確認するテスト
運用テスト
- 実際の運用環境でシステムが正常に動作するかを確認するテスト
アルファテスト
- 開発者以外の人が操作し、欠陥があるかを確認するテスト
ベータテスト
- 開発およびリリース前の製品を、開発者以外の一般ユーザーが操作し、欠陥がないかを確認するテスト

テスト技法

ホワイトボックステスト

ホワイトボックステストは、システムの内容を理解し、意識しながら行うテストを意味する。主に単体テストで使用され、次のテストに分類される。

制御フローテスト
データフローテスト

ホワイトボックステストを実行するときは、論理構造、つまり処理フローや実行順序を可視化する必要がある。その方法の1つがフローチャートである。

テストカバレッジ

テストカバレッジとは、システムまたはソフトウェアのテストについて論じるとき、テストがどれだけ十分であるかを表すものである。つまり、実行したテストがテスト対象をどれだけカバーしたかを比率で表す。

代表的なコードカバレッジは次のとおりである。

ステートメントカバレッジ(Statement Coverage)
- ライン(Line)カバレッジとも呼ばれる。コードの1行が1回以上実行されれば満たされる。
デシジョンカバレッジ(Decision Coverage)
- ブランチ(Branch)カバレッジとも呼ばれる。すべての条件式がtrue/falseを持てば満たされる。
コンディションカバレッジ(Condition Coverage)
- ここでの条件はすべての条件式を指す。内部条件がtrue/falseのケースを満たすかを見る。

その他にもコードカバレッジは存在する。

条件/判定カバレッジ(Condition/Decision Coverage)
改良条件/判定カバレッジ(Modified Condition/Decision Coverage)
複合条件カバレッジ(Multiple Condition Coverage)
経路カバレッジ(All Path Coverage)

ブラックボックステスト

ブラックボックステストは、ソフトウェアの内部構造や動作原理を知らない状態で動作を検査する方式である。

ホワイトボックステストを用いた単体テストが終わると、システムの内部構造を意識しないテストを進める。
主に機能テストとシステムテストに分類される。

ブラックボックステストでは、次の順序でテストを実行する。

試験の目的を定義する。
機能を洗い出す。
テスト観点を抽出する。例: フォームで投稿された値を確認する。
テスト観点を機能に割り当てる。

正常系ケース
異常系ケース
組み合わせたケース
etc.

テスト技法を決定する。

参考

コード分析ツール適用記 - 第1回、コードカバレッジ(Code Coverage)とは何か？

ユニットテスト

kc@example.com (kc kim) — Thu, 15 Sep 2022 20:08:00 +0900

ユニットテスト(Unit Testing)

ユニットテストは、次の基本ガイドラインに従って作成する。

パブリックメソッドをテストする。
テスト結果に影響を与える依存オブジェクトはモック化する。
ディスク関連の依存は可能な限り避ける。
ネットワーク関連の依存は使用しない。

言語別の単体テストフレームワーク

Java: JUnit
Kotlin: MockK

テストコードに対する個人的な考え

テストコードは一種の保険のようなものだと思う。
- つまり、コードを変更するときにテストコードがなければ、そのコードが本当に正しく動くのか不安になる。もしテストがあれば、その不安はなくなる。
- 人がコードを書く以上、誰でもミスをする。テストコードを書くと、発生し得るすべてのケースを考え、実行しながら証明できる。
- なくても運用はできるが、あると心強いものだと思う。
テストコードを書くことは、ロジックが正常に動作することの証明だと思う。
- コードが正常に動作するよう実装されていることの証明である。
テストコードは要求仕様書になり得る。
- ソースコードがどのような要求条件で、どのように動作するのかを把握できるようになる。

参考文書

JUnit Best Practices Guide | HowToDoInJava

TDD(Test Driven Development、テスト駆動開発)

kc@example.com (kc kim) — Thu, 30 Sep 2021 14:47:00 +0900

TDD(Test Driven Development)とは？

テスト駆動開発。
まずテストコードを作成し、それを使ってテストを行い、正しく動作しているかのフィードバックを受けながら進める開発方法である。
短い開発サイクルの繰り返しに依存する開発プロセスであり、開発者はまず要求される機能に対するテストケースを作成し、それに合うコードを書いてテストを通過させた後、状況に応じてリファクタリングする開発方式を意味する。
開発者はテストを書くために該当機能の要求事項を確実に理解する必要があるため、開発前に要求事項へ集中できるようになる。一方で、テストのための参入障壁や作成すべきコード量の増加は短所として挙げられる。

Mockとは？

実際のオブジェクトを作って使用するにはコストが大きい場合や、オブジェクト間の依存性が高く実装しにくい場合に作成する偽物のオブジェクトを指す。

Mockの使用例

テスト作成のための環境構築
テストが特定のケースや瞬間に依存する場合
テスト時間が長くかかる場合
個人PCやサーバーの性能問題により動作に時間がかかる場合

Mockitoとは？

ユニットテストのためのJava mocking frameworkである。
Javaの単体テストでMockオブジェクトをサポートするテストフレームワークである。
つまり、単体テストを行うためにMockを作成するフレームワークである。
Mockオブジェクトの生成、Mockオブジェクトの動作指定、そしてテスト対象ロジックが正しく実行されたかの確認が可能である。
一般的にSpringのようなWebアプリケーションを開発する場合、複数のオブジェクト間に依存関係が存在する。このような依存関係は単体テストの作成を難しくするが、それを解決するために偽物のオブジェクトを注入するMockitoライブラリを活用できる。
Mockitoを活用することで、偽物のオブジェクトに望む結果をStubし、単体テストを進めることができる。

Mockオブジェクトの依存性注入

Mockitoでは、Mock(偽物)オブジェクトの依存性注入のために主に3つのアノテーションが使われる。
- @Mock
  - Mockオブジェクトを作成して返すアノテーション
- @Spy
  - Stubしていないメソッドは元のメソッドをそのまま使用するアノテーション
- @InjectMocks
  - @Mockまたは@Spyで生成された偽物のオブジェクトを自動的に注入するアノテーション
  - 例えばUserControllerの単体テストを作成したいとき、UserServiceを使用しているなら、@Mockアノテーションで偽物のUserServiceを作成し、@InjectMocksでそれをUserControllerに注入できる。

BDD(Behavior Driven Development、振る舞い駆動開発)

kc@example.com (kc kim) — Wed, 29 Sep 2021 14:51:00 +0900

BDDとは？

BDD(Behavior Driven Development)は振る舞い駆動開発である。

BDDはTDDを基盤として派生した開発方法である。
TDD(Test Driven Development)からさらに一歩進み、テストケース自体が要求仕様になるようにする開発方法である。

BDDの基本パターン

BDDはシナリオを基にテストケースを作成し、関数単位のテストは推奨しない。シナリオは開発者ではない人が見ても理解できる程度のレベルが推奨される。

Feature: テスト対象の機能/責任を明示する。
Scenario: テスト目的に対する状況を説明する。
Given: シナリオの進行に必要な値を設定する。
When: シナリオを進行するために必要な条件を明示する。
Then: シナリオを完了したときに保証すべき結果を明示する。

作成例

@Test
fun `aliases for behavior driven development`() {
    // given
    given(calculatorService.add(20.0, 10.0)).willReturn(30.0)

    // when
    val result = calculatorService.add(20.0, 10.0)

    // then
    Assert.assertThat(30.0, CoreMatchers.`is`(result))
}

F.I.R.S.T原則

kc@example.com (kc kim) — Thu, 30 Sep 2021 14:47:00 +0900

F.I.R.S.T原則とは？

FIRST原則は、有名な書籍『Clean Code』の著者であるBob Martinが最初に提示した規則である。ユニットテストを構成するために、F.I.R.S.T原則に従う。

Fast

ユニットテストは素早く実行され、素早く結果が分かる必要がある。
そのため、行う作業の単位はできるだけ小さくなければならない。また、速いテストを行うには実際のサーバーやデータベースを使わず、偽物のデータ、つまりモックデータを作ってテストを進める必要がある。

Isolated / Independent

ユニットテストはそれ自体だけで実行される必要がある。
つまり、独立していなければならず、他のテストに依存したり影響を与えたりしてはならない。

Repeatable

ユニットテストは繰り返し可能でなければならない。
テストをどこで、どのように、何回実行しても同じ結果が出る必要がある。

Self-validating

ユニットテストは自己検証できなければならない。
テスト自体で成功か失敗かの結果が出る必要があり、それは自動的に行われなければならない。

Thorough / Timely

ユニットテストは徹底的で、適切なタイミングで作成されなければならない。
徹底的であるとは、すべてのデータを検査する必要があるということであり、最小から最大までの範囲を含め、役割によって変わるデータ、ユーザーの場合と管理者の場合の両方をテストできなければならない。また、どのケースが失敗、つまり例外やエラーになるかもテストしなければならない。

参考文書

FIRST Principles for Writing Good Unit Tests | HowToDoInJava

WebClientテスト - MockWebServerで外部API呼び出しメソッドをテストする

kc@example.com (kc kim) — Sat, 17 Dec 2022 16:31:28 +0900

概要

最近のほとんどのサービスではREST APIを呼び出すことが想定される。SpringはRESTクライアント構築のためにいくつかの選択肢を提供しており、WebClientを推奨している。

ここでは、WebClientを使ってAPIを呼び出すサービスを単体テストする方法を説明する。

MockWebServerとは？

Squareチームが作成したMockWebServerは、HTTP Requestを受け取りResponseを返す小さくシンプルなWebサーバーである。

WebClientやRestTemplateなどのClientを使ってHTTPを呼び出すメソッドのテストコードを書くとき、このMockWebServerを呼び出すようにすれば簡単にテストコードを書ける。Spring Teamもこの種のテストではMockWebServerの使用を推奨しているという。

簡単なWebClientプロジェクト作成

MockWebServerを使う前に、まずテスト対象となる簡単なWebClientプロジェクトを作成する。サンプルではSpring Initializrを使い、Java 11、Gradle、Spring Boot 2.7.6、webflux依存関係でプロジェクトを生成する。

データを受け取るDTOオブジェクトを作成し、WebClientで/users/{id}を呼び出してMono<User>を返すサービスコードを作成する。

MockWebServerの適用

依存関係の追加

MockWebServerを使用するため、テスト依存関係を追加する。

dependencies {
    testImplementation 'com.squareup.okhttp3:mockwebserver'
}

テストコードにMockWebServerを追加

テストコードでは、@BeforeAllでMockWebServerオブジェクトを作成して起動し、@AfterAllで終了する。

サービスにWebClientを生成して渡す

MockWebServerのポートを使ったbase URLでWebClientを作成し、サービスへ渡す。

@BeforeEach
void initialize() {
    final String baseUrl = String.format("http://localhost:%s", mockWebServer.getPort());
    final WebClient webClient = WebClient.create(baseUrl);
    userService = new UserService(webClient);
}

このようにすると、テスト実行時に実際の外部URLではなくMockWebServerが呼び出される。

任意のResponseを作成

MockResponseを作成し、bodyとheaderを設定してenqueueに入れる。MockWebServerはenqueueされた順番でレスポンスを返す。

Requestのチェック

レスポンス値だけでなく、takeRequest()を使ってリクエスト内容も確認できる。

final RecordedRequest recordedRequest = mockWebServer.takeRequest();
assertAll(
        () -> assertEquals("GET", recordedRequest.getMethod()),
        () -> assertEquals("/users/3", recordedRequest.getPath())
);

参照

上記のサンプルコードはGitHubで確認できる。

devkuma – Testing

テスト概要

テストの種類

単体テスト(Unit Test)

結合テスト(Integration Testing)

機能テスト

システムテスト

ユーザーテスト

テスト技法

ホワイトボックステスト

テストカバレッジ

ブラックボックステスト

参考

ユニットテスト

ユニットテスト(Unit Testing)

言語別の単体テストフレームワーク

テストコードに対する個人的な考え

参考文書

TDD(Test Driven Development、テスト駆動開発)

TDD(Test Driven Development)とは？

Mockとは？

Mockの使用例

Mockitoとは？

Mockオブジェクトの依存性注入

BDD(Behavior Driven Development、振る舞い駆動開発)

BDDとは？

BDDの基本パターン

作成例

関連動画

F.I.R.S.T原則

F.I.R.S.T原則とは？

Fast

Isolated / Independent

Repeatable

Self-validating

Thorough / Timely

参考文書

WebClientテスト - MockWebServerで外部API呼び出しメソッドをテストする

概要

MockWebServerとは？

簡単なWebClientプロジェクト作成

MockWebServerの適用

依存関係の追加

テストコードにMockWebServerを追加

サービスにWebClientを生成して渡す

任意のResponseを作成

Requestのチェック

参照