テスト戦略
下に行くほどハイレベルなテストになる
一般的に90%以上のカバレッジになる
カバレッジとソフトウェア品質の関係
コンポーネントはビジネスロジックをカプセル化しているので、それが正しいかのテスト
おおむねの異常系はユニットテストで担保されている
50%程度のカバレッジになる
仕様がテストとして実行できれば完了
テストを作る人
QAやビジネスアナリスト
コンポーネントの数が多いシステムで使う
コンポーネント間のやりとりをテストする
コンポーネントがうまく連携できているか（システムのアーキテクチャがただしいか）
ビジネスロジックのテストではない。それはコンポーネントテストで担保する
実行時間がながいので、CIには含めない。必要な間隔（毎晩とか）で行う
UIを使ったテストになる
テストを作る人
設計者
システムのアーキテクト
結合したシステム全体に対するインテグレーションテスト
システムが正しく接続しているかという構造をテストする
これも、ビジネスロジックのテストではない
コンポーネントの振る舞いの正しさはコンポーネントテストですでに担保されている
システムの10%のカバレッジになる
テストを作る人
システムのアーキテクト
テックリード
ツール：インテグレーションテストと同様
仕様化も自動化もできないテスト
人力でシステムをぶんなぐる
人間が操作して異常をみつけるテスト
kadoyau.icon
コンポーネントテストとインテグレーションテストとシステムテストのそれぞれの境界は？
明らかな場合もあるし、曖昧な場合もありそう
table:テストを作成する人
段階 誰が作るか
ユニットテスト 開発者
コンポーネントテスト QA、ビジネスアナリスト
インテグレーションテスト 設計者、システムのアーキテクト
システムテスト システムのアーキテクト、テックリード
手動探索テスト デバッガ
kadoyau.icon
一般的なWeb開発のチームでは開発者=設計者=アーキテクトになることも普通なはず
名前がややこしいいので、人によって認識がまちまちになってしまう問題
対応：確認項目の区分ごとにSmall/Medium/Largeで整理する方法もある
What do you call a test that tests your application through its UI? An end-to-end test? A functional test? A system test? A selenium test? I’ve heard all them, and more. I reckon you have too. Tests running against less of the stack? The same equally frustrating inconsistency. Just what, exactly, is an integration test? A unit test? How do we name these things?
リンク先の表を見よ
A Small test equates neatly to a unit test
a Large test to an end-to-end or system test
a Medium test to tests that ensure that two tiers in an application can communicate properly (often called an integration test).
それから10年以上たった今になっても、単体テストとか結合テストとかの用語にみんなが合意できる定義はない、と思う。この記事は、ここから Small, Medium, Large というデータドリブンな定義に進むのだけど、個人的には、この離散的な定義もあんまり好きではない。
これで問題はどう起こるのだろう？
良いテスト
偽陽性や偽陰性が少ないとチームが確信できること
信頼不能テストが1%に近づくとテストは価値を失う
Googleは0.15%に止めるように頑張っている
良いテストのためには
脆いテストは少なくする
カバレッジやロジックのテストへの漏れ出しを防ぐ
https://gyazo.com/6b51591bad5812179d69bdee733201b7
最初は手動テストしかないので、が