KotlinとJUnitの良いテストを書くコツ
Sal
kotlin 1. 曖昧さのない正確な仕様書として機能するため。具体的なテストケースを通すプロダクトコードを書く必要があるので、ユニットテストのテストケース自体が曖昧さのない仕様書として機能する。2. 進捗のフィードバックとして機能する。テストを実行しながら並行で開発をするめることで、開発の不安が少なくなる。

KotlinとJUnitの良いテストを書くコツ

  1. ユニットテストはなぜ行う必要があるのか?
  2. 良いユニットテストの条件5つ
  3. # 仕様書として読めるように分かりやすく書かれている
  4. # 可読性を維持するためにテストコードが適切に整理されている
  5. # 問題を特定できるレベル、粒度で書く
  6. # テストケース同士で依存が発生していない
  7. # 成功するか失敗するか分からない不安定なテストが放置されていない
  8. ソフトウェアテストの4フェーズ
  9. # 事前準備
  10. # 実行
  11. # 検証
  12. # 後処理
  13. (備考)二種類のテスト
  14. ユニットテストのパターン
  15. 備考
## ユニットテストはなぜ行う必要があるのか?
1. 曖昧さのない正確な仕様書として機能するため 具体的なテストケースを通すプロダクトコードを書く必要があるので、 ユニットテストのテストケース自体が曖昧さのない仕様書として機能する 2. 進捗のフィードバックとして機能する テストを実行しながら並行で開発をするめることで、開発の不安が少なくなる。
結果として**ソフトウェアの品質が向上する**
## 良いユニットテストの条件5つ
1. 仕様書として読めるように分かりやすく書かれている 2. 可読性を維持するためにテストコードが適切に整理されている 3. 問題を特定できるレベル、粒度で書く 4. テストケース同士で依存が発生していない 5. 成功するか失敗するか分からない不安定なテストが放置されていない
### 仕様書として読めるように分かりやすく書かれている
テストメソッド名を具体的に表現したり、メソッドの中野記述もなるべくテスト意図が伝わるように意識して記述する
### 可読性を維持するためにテストコードが適切に整理されている
JUnit等のテスティングフレームワークを使った気受した、 自動化されたテストコードはプロダクトコード同様、きちんと管理する必要がある。
### 問題を特定できるレベル、粒度で書く
テストメソッドが大きすぎると、テストが失敗した原因が分かりずらい。 一つのテストに対しては、一つの問題を扱う様にしよう
### テストケース同士で依存が発生していない
テストの結果が他のテストやオブジェクトに依存していては、テスト対象以外位の要素で結果が変わってしまう。 テストAの成功結果がメソッドBの結果で左右されてしまう等。
### 成功するか失敗するか分からない不安定なテストが放置されていない
不安定なテストは「レッドバー」を無視するような文化が発生してしまう。 開発の進捗状況は「グリーンバー」の数でフィードバックしよう。
## ソフトウェアテストの4フェーズ
1. 事前準備 2. 実行 3. 検証 4. 後処理 この4フェーズにテストユニットは分かれる。
### 事前準備
テスト対象オブジェクトの(SUT)の初期化、入力や期待値の用意
### 実行
SUTのテストの操作を行う
### 検証
テストの結果として得られた実測値が期待する結果と一致するか比較検証
### 後処理
次のテストの実行に影響が出ないようにする

@Test
fun 要素が二つの時にremoveAtで先頭要素を除くとsizeが1になる(){
    // 事前準備
    val sut = mutableListOf()
    sut.add("Hello")
    sut.add("World")
    // 2実行
    sut.removeAt(1)
    // 比較
    assertThat(sut).hasSize(1)
    assertThat(sui[0]).isEqualTo("World")
}
## (備考)二種類のテスト
ソフトウェアテストはテストケースの作り方によって大きく二種類に分かれる - ホワイトボックステスト 内部のロジックや仕様を考慮してテストケースを作成する ロジックなどを読み取れる必要があるので、ある程度プログラミングの知識が必要となる。 内部のロジックが正しく動いているのかまで把握する。 デメリット)テストコードが内部構造に強く依存してしまうと、テストコードがプロダクトコードの変更に影響が与えられる。 - ブラックボックステスト ソフトウェアの内部のロジックや仕様を考慮せず、外部から見たときの仕様のみからテストケースを作成する 業務の知識が必要。 デメリット)入力が簡単だが、複雑なテストをできない
## ユニットテストのパターン
ユニットテストはいくつかのパターンがある 1. 標準的な振る舞いを検証するテスト 初期化・実行・検証・後処理の4つのフェーズで構成される最も一般的なテスト 2. 例外を検証するテスト(異常系) メソッドの実行時に例外が想定通りに投げられる事を検証するテスト 3. コンストラクタを検証するテスト テスト対象クラスのインスタンスを生成してコンストラクタを検証するテスト

@Test
fun コンストラクタのテスト() {
    val taro = Person("Taro, 30)
    assertThat(taro.name).isEqualTo("Taro")
    assertThat(taro.age).isEqualTo(30)
}
## 備考
title:KotlinとJUnitの良いテストを書くコツ description:1. 曖昧さのない正確な仕様書として機能するため。具体的なテストケースを通すプロダクトコードを書く必要があるので、ユニットテストのテストケース自体が曖昧さのない仕様書として機能する。2. 進捗のフィードバックとして機能する。テストを実行しながら並行で開発をするめることで、開発の不安が少なくなる。 img:https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRmucaKbgWgJTHfHMMdUFAziBpyeB-GNVTnrQrRHJ46re_871oNfxeUkcxdp5RNQaalwc8&usqp=CAU category_script:True