The Clean Coder ch7 Acceptance Testing
Acceptance Testing
- GIGO
- garbage-in-garbage-out
- 【意訳】要件や仕様がしくじっていると何作っても無駄
- だからプロのプログラマはコミュニケーションに気を配る
- チームと・ビジネスサイドと
- 正確で健全であること
Communicating Requirements
- プログラマとビジネスの間のコミュニケーションのごくありふれた課題: 要件定義
- トム(ドメインサイド): 「自分で作るからプログラミング教えて」
- 簡易言語とはいえ、トムが思っていたよりは難しく、トムはモチベーションを失った
- ペア作業に切り替えた
- フィードバックループは5分サイクルくらい
- 当時のマシンでは実現不能な要求については逆提案したりした
- トム「望んでたものとなんだか違うから、別の方法にしよう」
- いろいろいじくり回して形にしていった
- トムは彫刻家
- ボブは道具
- 教訓
- 実際にプログラミングしてみないと欲しい機能が見えてこなかったりする
Premature Precision
- ビジネスサイド: プロジェクトにGOを出す前に何が納品されるか正確に知りたい
- 開発者サイド: 見積もる前に何を納品すればよいか正確に知りたい
- 無理
The Uncertainty Principle
- 【補】量子論の「不確定性原理」に引っ掛けている
- 観測者効果
- 動いているものを見て初めて「これほしいものと違う…」とわかる
- はじめ要件を詰めたところで、システムが実装されていくにしたがって当初の要件からは乖離していく
Estimation Anxiety
- 見積もりには正確な要件定義が必要だと思いがち
- 反論
- そもそも、情報が完全でも見積もりにはブレが生じる
- 不確定性原理につき、早期に正確を期したところでどうせ台無しになる
- 要件が変わるので
- 見積もりは見積もり
- 強調するために見積もりにはエラーバーを含める
Late Ambiguity
- premature precisionを避けるには: 決断をなるべく先送りにする
- 開発者は、実際に開発に取り掛かるまで、要件に肉付けしない
- 代わりにlate ambiguityに陥りがち
- そもそもステークホルダ間で意見が合わないこともしばしば
- ステークホルダは意見の不一致を解決するのではなく、言葉巧みに隠してしまいがち
要件定義書のあいまいさは、ステークホルダ間の論争のあらわれである (Tom DeMarco)
- あいまいさの原因は意見の不一致だけではない
- ハイコンテキストで開発者に理解できないということも
- 「毎晩ログを保存して」
- 開発者: 毎晩保存し、最新の1日分を保持すると解釈
- ビジネスサイド: 何ヶ月・何年分も欠かさず取っておいてほしい
Acceptance Tests
The Definition of "Done"
- プログラマ「終わりました」
- もうデプロイできる、の意？
- QAチームにテストを依頼できる、の意？
- 手元で1回動かした、テストはまだ、の意？
- doneとdone-doneを使い分ける現場も…
- プロのプログラマの定義:
- すべて書き終えて、すぺてのテストがパスし、QAとステークホルダーが受け入れた
- すばやいイテレーションと両立するために、受け入れテストを自動化する
- ステークホルダ、開発者、テスター一丸となって作る
Communication
- 受け入れテストの目的
- コミュニケーション
- 明確さ
- 正確さ
- 受け入れテストを作る過程で見逃しや考慮漏れに気づく
Automation
- テストにも色々な種類があり、手作業のテストは無くせないが、受け入れテストは常に自動すべき
- 手作業テストのコストは甚大
- 受け入れテストの自動化はプロのプログラマの責任
- 巷のBDDフレームワーク等を使えば、非プログラマでも読み書きできたりする
Extra Work
- 自動化受け入れテストは仕様定義
- doneの定義として必要
- 間違ったものを作ってしまうことの防止
- むしろ時間とお金を大いに節約できる
Who Writes Acceptance Tests, And When?
- ステークホルダーとQAが協力して書けるのが理想
- 現実的には、ステークホルダーではなくビジネスアナリスト、QA、ひいては開発者が代わりに書くことになる
- 開発者が書く場合は、機能の実装者とテスト作成者は兼任しないこと
- 傾向
- (要件は変わるので)書き始めるのはなるべく遅く
- 最初の数個はイテレーションの最初の日に
- 残りはイテレーション中間までに書き終える
- 間に合わなければ増員
- 慢性的に間に合わなければビジネスアナリスト、QAを増員せよ
The Developer's Role
- 受け入れテストをシステムと繋ぎ、redをgreenにするのが開発者のつとめ
Test Negotiation and Passive Aggression
- テストを書くのは人間
- テストがあまり意味を為さないこともある
- テストが複雑すぎることもある
- テストがぎこちないこともある
- テストの前提が馬鹿げていることもある
- テストが間違っていることもある
- 開発者はテストを通さなければならないので、こういう時とてもフラストレーションが溜まる
- テスト作成者と交渉して、テストをより良くするのも仕事のうち
- 受動的攻撃行動に出るのは最悪
- 「テストがこう言うんだからそのとおり実装しましたよ」
- 開発者がテストを改善する例: 性能要件のテストで、100%は言い切れないので、統計を用いる
- 提案、背後にある数学的裏付けの資料提供などは開発者の責任
Acceptance Tests and Unit Tests
- Unit Testは、プログラマによるプログラマのためのテスト
- プログラマが読むもの
- 低水準の構造・振る舞いの仕様書
- Acceptance Testは、本質はビジネスサイドによるビジネスサイドのためのテスト
- (開発者が代わりに書くことはあるけれど)
- ビジネスサイドとプログラマが読むもの
- 同じSUTをテストするとしても、冗長ではない
- 仕組みも処理パスも異なる
- 自動テストは「たまたまテストである」のであって、主目的は仕様のドキュメンテーションである
- ドキュメントの読み手が異なるので冗長でない
GUIs and Other Complications
- GUIの仕様を前もって決めるのは難しい
- できなくはないが、良いものにはならない
- UI/UXは主観的であり、ゆえに揮発しやすいから
- SRP原則はGUIにもあてはまる
- 異なる変更理由のものを混ぜない
- 同じ変更理由のものをまとめる
- 抽象的であまり変わらないものに対して記述する
- good: 「ok_buttonをクリック」
- bad: 「グリッドの4行3列目のボタンをクリック」
Testing through the Right Interface
- GUIとAPIを分離し、APIをテストする
- GUIの絡むテストは、GUIの変更により壊れやすい
- 捨てられがち
- GUIの変更が億劫になりがち
- そのテスト、GUIを通す必要がありますか
- GUIそのものの振る舞いの受け入れテストが必要なこともある
- 裏を返せば、ビジネスルールと紐付けてテストする必要がない
- GUIテストは最小限に
Continuous Integration
- 単体テスト・受け入れテストをCIで自動実行せよ
Stop the Presses
- CIテストは常に動き、落ちないことが大事
- 落ちたら緊急事態ととらえよ
- 落ちるのが常習化して「そのうち直す」は駄目
- 「落ちるテストを一時的に外す」も駄目
- 戻し忘れて客先でバグが出るのがオチ
Conclusion
- プログラマとステークホルダーとの間で認識の齟齬が生じがち
- 著者見解では、この溝を埋める術は自動化受け入れテストの他にない
- 自動化受け入れテストは、完璧な要件定義資料である
- フォーマルで実行可能
- 曖昧さがない
- アプリケーションの実装と乖離することがない
- フォーマルで実行可能
英語
- fraught with error
- 緊張感でいっぱいで
- naivete
- お人好し
- rudimentary
- 基本の、初歩の
- fiddle
- (自動詞)いじくる
- poke
- つつく
- prod
- つつく
- make hash out of
- ...を台無しにする
- moot
- 非現実的
- malady
- 病気
- wordsmith
- ことばたくみ
- disagree
- (自動詞)[主語]どうしが意見を異にする
- inclination
- 傾向
- passive-aggressive
- in flux
- なかなか結論に至らない
- stop the presses!
- (特ダネが入ったから)印刷機を止めて！
- 転じて、緊急時に待ったをかけること
- (特ダネが入ったから)印刷機を止めて！
