# 09. Xunit Testing
________________________________________
UnitTest  
https://martinfowler.com/bliki/UnitTest.html

JUnit実践入門 体系的に学ぶユニットテストの技法  
https://gihyo.jp/book/2012/978-4-7741-5377-3

.NET Core と .NET Standard での単体テストのベスト プラクティス  
https://docs.microsoft.com/ja-jp/dotnet/core/testing/unit-testing-best-practices

________________________________________
## 1. 要約
________________________________________
テストコードの効果

```text
1. 最も信頼できる仕様書になる
2. 詳細仕様が明確になる
3. テスト作成に伴い仕様バグも見つかる
```

XUnit testingするべきところ、するべきでないところ

```text
[効果的な分野]
1. 状態を持たない（副作用のない）純粋な関数ロジック
2. コンストラクタDIパターンが適用されたロジック
3. 1、2を満たすビジネスロジック（ドメイン層、Model）の検証
    1. ビジネスロジックにある事前条件、事後条件、オブジェクト不変条件、Assertion
    2. ビジネスロジックにあるValidation
4. DB検証
    - Viewの検証
    - 整合性検証（テーブル定義で表現されないが仕様上前提とされる制約・ルール）
5. UI（アプリケーション層、View・Controller）の一部
    1. ハッピーパスシナリオ

[効果的ではない分野]
1. コンストラクタDIを適用してしまうと過剰に複雑になるため採用しなかったプログラム全般
2. DAO
3. UI（アプリケーション層、View・Controller）の大半
```

テストコードの書き方

```text
[書く内容]
1. 前提条件（arrange）
2. 対象の振る舞いの記録(act)
3. 期待される結果との検証(assert)

[効果的な検証方針]
- ブラックボックステスト
- 同値クラステスト
- 境界値テスト

[テストコードの原則]
1. いつでも何度でも実行できること
    - 検証内容によっては、データソースリセット含む
2. 検証内容に対する結果を一定にすること
    - 現在時刻に依存する機能はうまく検証方法を考えること
3. テストケースが仕様書として読めること
4. テスト失敗時に問題を特定しやすいこと
5. 可読性の低いテストコードは避けること
6. テストケースは順序に依存しないこと。並列実行できること
    - 最近のテストランナーは並列実行が前提になっている
```

※ 以下の記事も参照のこと

- # 20. DevOps
- # 20ex1. DevOpsの実践