take2 は https://github.com/haru01/log/blob/master/pattern_sheed.md
TDDを 初心者が熟練者になって、現場で実践していくコツを書いていきます。 すべて実施する必要はありません。上から順に実施する必要もありません。 現状の診断や、自分の状況に合いそうなものを複数ピックアップして、 ベイビーステップで個人やチームの学習と成長の物語を描く道具として使われることを想定しています。
まだ未完です。ガンガン変わっていきます。 :p
目標 25個、 50個 練習場編、現場実践編、不吉な匂いの３本立て。
TDDを開発の現場に持ち込みたいと考えている人。持ち込んで継続したいと考えている人。継続して広げていきたいと考えている人。 読者の現場によって、選ぶパタンは異なる。
ここで指すTDDは、XPの意図を汲み取って、BDD、GOOSと同様に、Acceptance Testも 範囲内としてTDDを語る。ただし、エンドユーザの実際の使用からの学習フィードバックループを 取り込む活動については、予感のみにとどめTDDの範囲外として語る。
Acceptance TestもTDDの範囲内とするが、導入ステップを、アウトサイド・イン、 インサイド・アウトどちらで攻めるかのオススメは保留し、現場の判断とする。
- 健全性
- 小さなステップ
- 早く失敗し、学びを得る
- マシンとの対話、人との対話
- 多重のフィードバックループ
あとで書く
私は、テストの書き方を練習しようとしています。 が、私は、今まで、テスティングフレームワーク,CIを触ったことがありません。
ツールなしには、私はテストを書くこと、実行すること、実行結果を見ることはできません。 テストハーネスなしにTDDを始めることはできないでしょう。
それゆえ
試しに自分のマシンにテストの実行環境を用意しよう。
環境があれば、実際に手で触って試して学ぶことができます。
- 使用する言語に合わせてテスティングフレームワークをインストール、実行し、 Red、 Greenを確認してみよう。
- コマンドラインから ALLテストの実行の方法を を調べてみよう。
- ファイルを保存したら、即テスト実行する環境を調べてみよう。Ruby であれば Guard が参考になります。 JavaScript / mocha を使っているなら --watchオプションが参考になります。
- 使用する言語に合わせて、GUI向けの自動テスティングフレームワークを準備してみよう。
- Cucumberなど BDDテスティングフレームワークの記述と実行を試してみよう。
- CIをインストールしてみよう。ALLテストを CIから実行してみよう。カバレッジレポートを出してくれるツールを調べてみよう。
私は、普段、Red Green Refactor のサイクルでプログラミングをプログラミングしていません。 いつもは、デバッカー、println、外側から【目視】で動作確認しています。
Red Green Refactorのリズムを己の肉体で魂で実体験したことがなく、一体何がおきているかさっぱりわかりません。
それゆえ
とてもとても簡単なお題を Red Green Refactor のリズムで、解いてみよう。
実際に体を動かして試して心で感じることが、TDDを理解し始める一歩となります。
- Red Green Refactorのボードを用意してみよう。自分が現在どのフェーズにいるか確認しながら、TDDを進めよう。
- 四則演算やFizzBuzzなどとても簡単な問題を Red Green Refactor で 解いてみよう。
- もう一度 FizzBuzz 問題を解いてみよう。今度は、１回目よりも、Red Green Refactorサイクルを短くリズムよくすすめるように工夫しよう。
- プログラミングの際は、デバッカー、println、マウスの利用を禁止しよう。代わりに、assertで確認することを徹底しよう。
- TDDBCのお題、Code Kataなどを参考に、問題の難易度を上げてみよう。
- 解いたあとに、TDD練習のふりかえりをしてみよう。（何をして何を感じたか？学んだことは？今後、取り入れたいことは？）
Red-Green-Refactorのリズムが馴染めず、私の体と心がTDDの拒絶反応を示している。 どうしても、Red Green Refactorが慣れないのであれば、 Red Green Refactorの制約を緩める。 ちょっと実装して、ちょっとテストを書いて、リファクタリングするを繰り返すですすめる。 ある程度進めたところで、既に書いたてテストを参考に、先にテストを書くを試みてみる。
別名： 量は質に転化する。練習、練習、練習。写経
私は、まだTDDを勉強し始めたばかりで、Red Green Refactorのリズムがまだ、体と頭に染み付いていません。
実プロジェクトではじめようにも、なかなか思うようにTDDでプログラミングができず、もどかしい思いをしています。 うまくテストから書き出すことができないので、実装からはじめて、テストのこと忘れてしまいます。
[Kode Kataの説明、練習の重要性の説明を 引用ベースで]
それゆえ 安心して失敗して学ぶことが出来る練習時間を用意しよう。簡単なお題をTDDで何度も何度も解いてみよう。
何度も繰り返すことで、Red Green Refactorのリズムが体と心が馴染みます。 繰り返すことで、だんだんとTDDのリズムが刻めるようになります。各々のテスティングフレームワークやテスト用のライブラリーも語彙・イディオムに癖があります。練習しておくと頭が指がスムーズに動くようになります。 練習は、本番とは異なり安心して失敗できる場です。はじめは躓く事が多いでしょうが、そこから学びがあるはずです。
- Kent Beck本を使って本のとおりに記述(写経)してみよう。Rails であれば Rails Tutorial を参考に、写経してみよう。
- Code Kata や TDDBCのお題 をネットで調べ、TDDでチャレンジしてみよう。ボーリングゲーム、ローマ数字の足し算、ライフゲーム, 自動販売機 etc...
- テスティングフレームワークを幾つか触って違いを観てみよう。
- UIからの自動テストを実施するテスト支援のライブラリーを幾つか触ってみよう。 Ruby であれば、Capybaraが代表格である。
- 前提データをデータベースに投入するテスト支援ツールのライブラリーを幾つか触ってみよう。Ruby であれば、 FactoryGirl, Fabrication が代表格である。
- ビジネスサイドとのコラボレーション支援することを意図した Given-When-Then 形式の フレームワークを触ってみよう。表形式でまとめる Fitを触ってみよう
- 簡単なTODOリストの作成をお題に、UIからGiven-When-Then形式でテストを書いてから実装してみよう。前提データを用紙するライブラリーも使用してみよう。
- TDDBC や Coderetreat などのイベント参加して、素振りしてみよう。
- 実プロジェクト、練習お題ともに、TDD熟練者とペアプロしながらTDDに取り組んでみよう。経験者のTDDのススメ方を真似てみよう。
- 朝、週末の練習後にもう一度、実プロジェクトで簡単なテスト対象お題を見つけてトライしてみよう。
TDDのWebの動画、ペアプロ、TDDBCなどの機会を通じて経験者のTDDの進め方を目で見て、真似てみる。
私は、１人でTDDを学ぶことに心細さを感じています。
個人の独学だけでは、限界があります。身の回りにもTDDを実践している人がおらず質問する人がいません。
それゆえ
TDDBCもしくはそれ相当のハンズオンセミナーに参加しよう。
TDDBCに参加できれば、経験者による実際のRed Green Refactorの動きを見ることができ、 疑問感じていることを質問して解消することができます。
また、経験者のTDD過程を実際に自分の目の前で見ることで新しい発見が期待できます。 初めてTDDを目撃する人にとっては、Red Green Refactorのサイクルの短さに何かしら驚きと発見を見出すようです。 真似て学ぶことができます。
- 気の合う同僚を見つけて、一緒に参加しよう。参加後の帰り道で意見交換しよう。会社に戻って、類似イベントを開催してみよう。
- コードレビュー機会で、普段自分が記述しないようなイディオムなどきれいなコードを学ぼう。
リファクタリングで、動作する「汚いコード」から「きれいなコード」変換せよというけれど、私は、何が汚いか綺麗かの判別できません。
動作するきれいなコードの「きれいなコード」ってなんだ？
それゆえ
一旦TDDは脇に置いて、不吉な匂い、言語のイディオム、パターン、設計原理について学ぼう。不吉な匂い、イディオム、パターン、設計原理を使ってコードについて語り合おう Greenの際に、どこをリファクタリングすればよいかわかります。良い名前付けができるようになります。 テストで使用例のサンプルコードを記述する際よりベターのAPI設計ができるようになります。
- リファクタリングで語られる、「不吉な匂い」を調べてみよう。 現状のコードについて「不吉な匂い」を使って語り、同じ症状に陥っているか否かを診断してみよう。 例えば「長すぎるメソッド」「基本データ型への執着」などの症状に陥っていないかを検討してみよう。
- http://www.objectclub.jp/technicaldoc/refactoring/refact-smell
- 各言語でよく使われる記述のイディオムを調べてみよう。例えば、Rubyであれば 書籍「メタプログラミングRuby」の付録が参考になります。
- http://qiita.com/jnchito/items/dedb3b889ab226933ccf?utm_source=Qiita+Newsletter+Users&utm_campaign=3621e960de-Qiita_newsletter_79_20_11_2013&utm_medium=email&utm_term=0_e44feaa081-3621e960de-32740073
- 書籍「リーダブルコード」や「コードコンプリート」などを読んでみよう。 名前付け、コメントの付け方、テスト名の付け方などについて学び、自分の記述しているコードとの違いを把握しよう。
- オープンソースのプロダクトを１つか２つ選び、読んでみよう。 使われているイディオムやパターンが自分の書いているコードにも適応できないか検討してみよう。
- 「オブジェクト指向エクササイズ」を調べてみよう。実際にこの縛りでお題「ライフゲーム」「数独」「自動販売機」などを解いてみよう。
- http://hiroki.jp/2012/08/30/5447/
- ソフトウェアの設計原則を調べてみよう。SOLID原則について調べてみよう。その他にもある設計原則を調べてみよう。(DRY,名前重要,GRASPパターン,...)
- http://d.hatena.ne.jp/asakichy/20090122/1232879842
- 上記で学んだ不吉な匂い、イディオム、パターン、設計原理を使って、 気の合う同僚や師とコードについて語り合ってみよう。どうすれば、どうすればテストしやすいコードになるか、読みやすいコードになるか、 メンテナンスしやすいコードになるか、を話し合ってみよう。
- コードレビューしてもらおう。第三者の目で指摘してもらおう。
not 工程単位
- TDD熟練者とのペアプロ
- テスティングフレームワークの文法学習
- xUnit の 語彙体系の学習
- バリューオブジェクト指向の学習
- 状態管理型オブジェクト指向の学習
- メッセージ型オブジェクト指向の学習
- テストダブルの学習
- ソフトウェア設計原理の学習
- 読書リスト
- TDD練習のふりかえり
- オープンソースのテストコードのリーディング
- きれいなコード
- グリーンを保つ
- テストのコードレビュー
時間外で、テスト環境準備、テストを書き出し
新しい取り組みを始める際は、Why（なぜ必要？効果は？）を周囲から問われることがあります。
TDDのメリットをコードから距離のあるビジネス側やマネージャの人を説得するのは難しいです。 今の段階は、許可を求めず謝罪せよが良さそうな予感がします。
それゆえ
特に周りを説得せずに、ひっそり始めましょう。 TDDは一人でも始めることができるプラクティスです。特に肩肘はらず「TDDをやっている」などとは言わず、 「プログラミングしている」と言いましょう。 上司への説得コストは下げて、現場で開始することができます。
- ユニットテストが記述できるだけの「テストハーネスの準備」をしよう。
- 特に「TDDやってます」「TDDをやるので時間を下さい」と周囲には言わないこと。許可を求めず始めてしまおう。
- まずは高いカバレッジ、すべて自動化などは目指さず、 Unit Testing したほうがよい、テスト対象を探してみよう。 （目視で繰り返し確認が手間,POJOクラスでドメインロジックが複雑）
- どうしても、手と頭が動かない場合は、週末などに「素振り」で「Red Green Refactorのリズム」を体と頭に叩きなおして、再チャレンジしよう。
- 「時間がない」で根本対処が難しい場合は、無理せずタイムボックストライアルで、制限の時間枠内のみTDDを試してみましょう。
- 特に強い説得を必要としないフォローアーになってくれる「気の合う同僚」を見つけ,2人でひっそり始めよう。
私は、新しい取り組みを始めるにも、スケジュールがきつく「時間がない」と感じています。 チームで、「ワークキューの流量制限」「時間泥棒の逮捕」「プログラミングの完了条件の明確化」 の実施で時間を確保することが難しいと感じています。
新しいことを学ぶことに時間がかかります。プロジェクトが多忙です。 フルタイムでTDDを実施しながらタスクを完了させることにハードールが高いと感じています。
それゆえ
私が出来る範囲内にTDDの実施を限定しましょう。タイムボックスを決めて、小さくトライしましょう。 例えば、多忙プロジェクトでも週に4hだけTDDにトライアルすると決めて、実施しましょう。 多忙の中でも、実プロダクトでTDDを小さくトライすることで、練習では得られない現場での学びが得られます。
- 週に TDDにトライアルする実施可能な時間枠を決めましょう。例えば、週に 4h。
- Unit Testingで実施すると良さそうなテスト対象を見つけて取り組みましょう。
- （外部ライブラリーやフレームワークや画面やデータベースや外部システムに非依存である、 ドメインロジックがそこそこ複雑で確認したいパターンが複数ある。繰り返し確認が手間である。）
- トライアルのタイムボックスの期限が来たら、継続するかやめるかを判断しましょう。
- 週n時間 TDDにトライアルするを１ヶ月実施してみましょう。
- タイムボックス トライアルを１ヶ月後に継続するか検討しましょう。
- 週に 2hを使って、テストハーネスも整えてきましょう。場合によっては時間外で。
- Unit Testing できる環境
- All Testが実行できる
- Mockライブラリーが使える
- CIを使って All Testが実行できる
- UI からテストできる
- 前提データのセットアップができる
- ....
不規則な「割り込み」と呼ばれる現象と呼ばれる現象が、「時間がない」を引き起こし、 「テストを書かない」に陥ることも 個人レベルで「割り込み」と呼ばれる現象にどのように対処していくか。 「一人を犠牲に」や、スクラムのような「見積りと計画づくり」が使えない。 割り込みタスクを入れ替えた際の、影響範囲をキチンと説明し、優先順位の話、期限に間に合わない話などをキチンとしてから仕事にとりかかる。
選んだテスティングフレーワーク、チェックスタイル、ビルド依存、実行までのロード、マシン、環境などによって、 短いサイクルで、Red Green Refactor ができずTDDの阻害要因となっている場合がある。
テストハーネスは準備しました。既存システムで今は１行もテストコードはありません。 私は、今、どっからTDDに取り組めば良いか途方にくれています。
それゆえ バグ再現と対処などTDDできる対象を見つけましょう。 １つでもテストが記述できれば、そこを参考にテストを成長させることができます。
現場のプロダクトにTDDを始める候補が幾つかありますので参考にしてください。
障害の再現テストを記述して直すをTDDでやってみる作戦。
- バグの再現テストを書きRedを確認しましょう。
- コードを読み、現象の原因分析、修正範囲を特定しましょう。
- 修正しGreenになることを確認しましょう。
- 必要があれば、修正範囲で不安に感じる場所は、自動テストを書きGreenになることを確認しましょう。修正する前に用意しても構いません。
新機能の実装の際に、TDD出来そうなところを探す作戦。
- 画面からDBまでのレイヤーをまたぐテストは除外します。
- 画面レベルで目視確認より、ユニットレベルで自動で動作確認したほうが開発が進めやすそうなターゲットを見つけてましょう。
- モデル(Value Object, Entity, Service)の順に、探してみましょう。
既存コードにテストを補強してから、TDDを開始する作戦。
- 内部のスパゲティコードに目をつぶります。
- 既存機能にUIについて、ビジネス上重要なものを選定します。 （UIはメンテしにくいタイプのテストになりがちなので、記述量は抑えます。書き始めの時は、カバレッジは、一旦目をつぶりましょう。）
- 次回以降の機能追加や修正の際に、既存テストを参考にして、テストを先に書くようにしましょう。
既存コードにテストを補強してから、TDDを開始する作戦。 レイヤの観点からではなく、ビジネス上の重要資産の観点で対象を見つける。
- UI, Service, Repository, Model, Value Object どれかは問いません。
- お金の決済まわり、止まったら業務上クリティカルになる、など重要となる箇所を選定しましょう。
- 既存に対してテストを補強しましょう。
- 次回以降、機能追加や修正の際に、既存テストを参考にテストを先に書くようにしましょう。
歯を食いしばって、テストの差し込み、テストしやすい設計に変えていく。
説得コストの低いフォローワーを見つける。１人よりも活動を継続しやすい。
バグ報告件数や手動テスト時間を測定し、次のアクションの判断材料にする。
ビジネス側やマネージャの関心ごとは、コードの質やテストの自動化よりも、 動くものが早くこの目で確認したいと感じています。直接TDDの嬉しさを伝えづらいと私は感じています。
TDDのメリットをコードから距離のあるマネージャの人を説得するのは難しいです。 だからといって「１人でひっそり」ではなくビジネスサイド・マネージャを巻き込んで活動を取り組んでいきたいです。
それゆえ
TDDは一旦脇に置いといて、１日以下サイクルで頻繁なデモから始めましょう。 デモ環境を通じて、ビジネス側・マネージャと開発者がつくっているものについて頻繁に会話してフィードバックできる、 信頼関係を醸成できる環境を用意しましょう。信頼関係を醸成できれば、TDD導入の理解が得られやすくなります。
- デモ環境のマシンを用意しましょう。
- デモ環境にデプロイするスクリプトを用意しましょう。
- CIを準備しましょう。コミット毎 or 定時ビルドでデモ環境へのデプロイを実施しましょう。（CIでAllテスト実行はありません。テストがないのですから）
- デモ環境を使って頻繁につくっているものについて非エンジニアと会話して、信頼関係を深めましょう。
- おそらく、壊れたものがデプロイされることもあるでしょう。 このタイミングで、壊れたものがデプロイされた原因や今後の防止策について話し合いましょう。
- コードを整理整頓してリーダブルコード（正常状態）を保つ重要性と現状のギャップについて話す
- 繰り返しテスト実行でグリーンを保つ(正常状態)重要性と現状のギャップについて話す
- TDDがギャップを解消する１つであると提示
- それでも了解されない場合は、今後も壊れたものがデプロイされることがあること、動くものベースに話をしてより良いもに変えていくフィードバック機会が減ること、追加や修正に手間取ること、 を了承してもらいましょう。（必要があれば、毒の沼地化したコードや自動テスト不在が原因でメンバーの体や心を壊してしまうや逃げ出してしまう確率が高まることもお伝えしましょう。）「１人でひっそり」「タイムボックストライアル」でほそぼそと続けて、機会をうかがいましょう。
- ビジネスサイドと開発側の認識のギャップが大きいことが問題に上がる場合は、メンテナンス性向上の設計カイゼンよりも、 Acceptance Testing を使ったビジネスサイドとのコラボレーションを先に取り組みましょう。
テストハーネスの準備、テスト対象の選定、テストの書き方などを自力で解決するのは難しい。 指導者によって、指導者が、複数のプロジェクトを巡回して、自動テストの対象の選定、テストハーネスの入れ方、テストの書き方などのコツを伝える。 指導者がいなければ、外部コーチを雇う。その役割を持った人を育てる。
ついつい、今までのお仕事の進め方に戻りがち。定着するまで口酸っぱく言い続ける人がいると良い。 ロールモデルは、Clean Coder の２章、３章のような発言をする人。スクラムマスターの完了マスターのような人
ついついマシンとの対話に熱中し、人との対話を怠ると、良質なテストパターン、動作するきれいなコード、よい設計に辿りつけない。
- マシンと対話： TDDはいわば開発者とマシンの対話。TDDの基本。テストの声を聞け。テスト（動作確認）が難しいなら設計がまずい。クラスやメソッドの使い方例をテストで書いて、わかりにくかったら設計がまずい。テスト結果のレポートの声を聞け。耳を澄ませば、次に何をすべきかを見つけられるはず。できないなら、レポート出力がまずい。
- ユーザや顧客と対話: 頻繁なデモに、顧客との対話から本来あるべき使える面白いソフトウェアの仕様の具体例（テストパターン）を見つける。
- 同僚ー指導者と対話： ペアプロやコードレビューなどの対話を通じて、より良いネーミング、設計を見つける。
- テスト専門家と対話： 開発者目線では、抜け漏れが発生しがちな、テストパターンを見つける。
- ドメインエキスパートと対話： ドメインに詳しい人と対話を通じて、ユビキタス言語の洗練、ドメインモデルの洗練。対話とコードを使って、対象ドメインに一歩寄り添う。
前述
通常、開発プロジェクトは多忙のことが多い。私は、日ごろの仕事の多忙に圧倒されています。
TDDなど新しいことを始めるよく出会う最大の敵は「時間がない」です。
それゆえ
新しく始める前に、不要な活動を削除し時間を確保することに注力しよう。
代表的な時間泥棒の逮捕は次で行われる。
-
不要なフィーチャの削除: つくる理由Whyを確認しよう。誰向けなのか？ なぜそれが必要か？ それがないと何に困るのか？ あると何が嬉しいのか？を確認しよう。
-
まともな理由が語られないのであれば、それは、価値を産まない無駄なフィーチャの可能性があります。削除、簡略化できないか提案しましょう。
-
逆に、ユーザー、顧客目線で必要とされる背景や理由を一歩寄り添って理解できれば、良質なテストパターンを記述出来る可能性が高まります。
-
不要な会議の削除: アジェンダ、自分の発言、会議後の結論、アクションを確認しよう。
-
アジェンダ、自分の発言、アクションがないのであれば、参加不要な会議の可能性が高です。
-
会議後に、チームで今後も必要・続けたい会議か投票しよう。ミーティングを改善できないか話し合ってみよう。
-
チャット、pull reqest、開発現場でのホワイトボードを使ったフェースツーフェースコミュニケーション、ペア作業などで代替できないか検討しよう。
-
見積りと計画づくり: 後述
-
不要なドキュメントの削除
-
席の配置
プログラミング完了ってどういう状態なんでしょうね？
人によって「プログラミング完了しました」の認識がバラバラです。自動テストが含まていたり、含まれていなかったりします。
現場では、（自動テストによる）動作確認までを行って完了とせず、嘘の進捗の「できました」になってることがあります。
したがって、
スクラムの完了の定義を参考に、完了した状態をチームで明らかにしましょう。テストは含まれる？
完了条件にテストが含まれれば、ユニットテストの作成の際にTDDが利用できます。
私は今、開発の計画づくりに参加していません。
計画づくりに参加していないと場合によっては、知らない所で非現実的な仕事量をすることが決まってしまうことがあります。 仕事量が多い場合、テストやコードレビューが省略されることがしばしば発生してしまいます。
開発のコンテキストにおいて、非現実的な仕事量を引き受けけた際、「時間がない」は、テストやコードレビューを省略した手抜きループが発生します。 が、これが後に、後からバグ発覚、度重なる手戻り修正、メンテ不能なコードとさらなる「時間がない」の悪循環の状況を作り出してしまいます。
したがって、
見積もりと計画づくりに取り組みましょう。1-2week当たりの私・私達ができる仕事量(コードレビュー、テスト込み)を把握し、手抜きなしの適量の仕事をこなせるように取り組みましょう。
適正な仕事量で実施できれば、「時間がない」によるテストを書かない、コードレビューがされないことによる、さらなる「時間がない」の悪循環ループを断ち切ることができます。
- 「見積り」「コミットメント」「ターゲット」の違いを調べましょう。「プログラマが知るべき97のこと」にも記載されています。
- SCRUM BOOT CANP, アジャイルサムライ、アジャイルな見積りと計画づくりを調べましょう。外部のワークショップで学んでみましょう。
- スクラムのDoneの定義、Clean Coderの開発の規律などを調べましょう。チームとしての開発の規律を明文化しましょう。
- 1-2week当たりで、テスト込みでできる仕事量を計測し続けましょう。
- 過去の実績をもとに、1-2week当たり、テスト込みで出来る範囲で、仕事をすると約束しましょう。
- 開発の規律を守り、テストなしで「終わりました」と、嘘の進捗を報告することはやめましょう。
「割り込み」がテストする時間が失われることがしばしば。
割り込みのコントロールが必要な場合も、一人を犠牲に、対応をとって、残りのメンバーは専念。 割り込みの優先順位を付けて今週やるか次週やるかをきちんとジャッジする。 障害であれば再現テストからTDDを
どこからどこまでの範囲を、どんな目的で、どんな道具を使って、セーフティネットを用意するかを明らかにする。
| 名前 | 範囲 | 目的 | 道具 |
|---|---|---|---|
| 頻繁なデモによるテスト | 人-マシン | 記述したテストの機能性に関する妥当性確認。新たなテストケースの発見 | デモ環境 |
| End to End 結合 | UIからDBまで。ただし外部Webサービスはスタブモック化 | 仕様の明瞭化。ただし記述レベルはPOとシェアしない。 進捗把握。 End to Endの疎通。ただし外部Webサービスとの結合は範囲外 | Request Spec, Capybara, FactoryGirl, webmock |
| (Service、Entity) - DB 結合 | Service、Entity DBまで | 複雑なQueryも含めてサービス、エンティティが期待通り動作するか。 ただし、サービスからDBまででドメインよりも、End to Endを優先して記述する方針。 | RSpec FactoryGirl |
| Entity, Value Object, Policy, Helper | ユニット。ユニット同士のつながり | コードや設計の改善。設計方針はSOLIDを参照。リーダブルコードを参照。開発の促進。複雑なドメインをテストで明瞭化し、期待通り振る舞うか確認。 | RSpec, RSpec Mock |
| スモークテスト | |||
| 注意) 開発促進のためのTDDを実施後、補強するテストパターンは改めてレビューと追加・修正を行う。 |
チームで、テストはそれなりに記述されるようになりました。だが、私は今何かがおかしいことが発生していると感じています。
テストが遅いなど何かおかしなことが起きています。他にも何かおかしなことが起きているのだが、うまく説明できません。
それゆえ
テストの不吉な匂いを参考に、現状のテストを診断してみよう。現状の診断と今後の対策をチームで話し合ってみよう
代表的なテストの不吉な匂いは次です。
- Developers Not Writing Tests
- High Test Maintenance Cost
- Hard-to-Test Code: 自動テストで動作確認が難しい構造になっている。
- Slow Test: 1つ、Allテストの実行時間が遅い。
- Fragile Test: ちょっとしたプロダクションコードの修正で、多数のテストが失敗してしまう。
- Manual Intervention: 前提データを手動でいれるなど、自動化が不十分である。
- Obscure Test: テスト記述の意図が不明確で、理解が難しい。
- Erratic Test: テストが成功したり、失敗したりと、結果が気まぐれである。
サイト先で、現象の原因についても記載されています。
- 次のサイトに目を通してみよう。http://devtesting.jp/pekema/?0004%2FTopics
- チームでテストに関して、困っていること話し合ってみよう。 対策アクションを1か２つ出して実施してみよう。
プロダクトオーナーと何を作るかの認識のギャップが大きな問題になっており、 私は、何を作るかについて具体化するコラボレーションを促進するための受け入れテストに取り組むべきと感じています。 （頻繁なデプロイと対話のみでは解消しきれません。） しかし、Cucumber、Fitなどの道具を導入し運用し続けるには、コストが高く、まだ難しいと感じています。
オーナーとの何を作るかで認識のギャップを小さくしたいです。が、Cucumber等のツール導入はハードルが高いと私は感じています。
したがって
表例、Given/When/Thenを使った会話のみ導入しましょう。 ツールの導入は別の機会を伺いましょう。Fit, Cucumberは 自動テスティングフレームワークと同時に エンジニアと非エンジニアのコラボレーションツールであることを忘れないで下さい。 ツールの導入運用コストは抑えつつ、フェースツーフェースのコラボレーションの質の高上が期待できます。 もちろのツール導入のメリットは得られませんが。(記述した仕様の具体例がそのままテストに使え、進捗把握が簡潔明瞭。リグレッション)
- Fitの文法（表形式）を調べましょう
- Cucumberの文法(Given, When, Then, Example)を調べましょう。
- ドメイン用語 + 表例、Given, When, Then, Exampleを使って, UI層から or サービス層からシステムの期待する振る舞いについてエンジニアと非エンジニアがペアで記述しましょう。
- この時点では、ペアで記述した内容が、実行可能な仕様でなくても構いません。
- 機が熟したら、Cucumber, Fitなどのツールの導入・運用を試みましょう。
ダーティコードは、頭痛吐き気を催し、健康被害をもたらす。動作するきれいなコードを目指して移動する（危険な場所を避ける）ことも選択肢としてはある。 （他の選択は、レガシーコード改善ガイドのように、レガシーコードのある世界にとどまり、頑張って動作するきれいなコード変えていく選択、諦めて過ごす選択。）
各イテレーションでちょっとづつテストを入れていく計画を立てる。 参考に出来るテストが増えれば、先にテストが書きやすくなる。
開発の規律 （DONEの定義）を破って仕事を続けて、身動きが取れなくなる前に。 ゴミコードを量産しない対策、準備をチームで話し合い、部分的なテストの補強、部分的なリファクタリングの猶予期間を設ける。例えば 1week。
- フレームワークとテスト
- ストーリーの受け入れ条件
- TDDとペアプロ
- UIテスト
- 気の合う同僚
- 師
- 弟子
- 技術負債とのお付き合い（名前の変更)
- バグ対応の現象再現にテストを書く
- 既存の重要なUIの振る舞いを見つけてテストを書く
- 新機能追加の際に仕様をテストで書く
- 受け入れテストを使った対話
- Acceptance Testのペア記述
- Acceptance Testの自動化
- 機能追加・修正しやすさの確認（名前の変更)
- 障害発生と対策方法
- ソースは嫁
- 多重フィードバックループの協調 （ユニットのRed Green Refactorの学習ループ、受け入れの学習ループ、コードレビューの学習ループ、 デモの学習ループ、 リリース後のユーザーの反応の学習ループ。。。を加速するレバレッジポインとしてのRed Green Refactor.）
-
TDD=テストですよね。（人が理解しやすいコードや設計の導く技法、デバッカーの代わりにテストと一緒にコードを記述するプログラミングの技法の１つの観点が抜け落ちている。TDDのみでは足らないテストパターンがある。）
-
失敗レポートのメッセージを読まない
-
private メソッドのテストの執着
-
モックテストフレームワークの機能の乱用
-
練習不足
-
時間がない
-
プリント、デバックの多用
-
Red Green Refactor の学習サイクルが長すぎる
-
長時間 Red
-
多数 Red
-
TODOリストの不在
-
仕様を把握していない
-
他者との対話時間不足
-
テストコードレビューの不在
-
遅すぎるテストコードレビュー
-
xUnit Patternsの不吉な匂い
-
プライベートメッソドをテストしたいんですけど
-
コードを変えずに、パワフルなモックツールでテスト書きたいんですけど
-
テストのメンテが難しくてやめてしまいました。
-
設計者と実装者の分離が阻害要因
-
テスターとプログラマの分離が阻害要因
-
物理的・空間的に分離がTDDの学習フィードバックを阻害している。
人の上下関係等によっては、ビジネスサイドと開発サイドで発言力が対等にない場合がある。 よくある失敗シナリオとして、ビジネスサイドの「ターゲット」の希望のみで、実作業者の開発者による「見積り」はなく、 達成不可のスケジュール「コミット」していることが発生している。 その後に起こることは、開発者はテストやコードレビューを諦め、内部品質を犠牲にし、モンスター化ー毒の沼地化したコード残骸に目をつぶりながら、なんとか動くものをだす。 だが、悪夢が待ち受けている（誰も既存のシステムの期待する振る舞いを知らない、吐き気を催す酷いコードで追加修正が困難。 祈りながら追加修正するが、ぶっ壊れて障害対応。使い手も作り手も不幸の結末を呼び寄せる。）。
【実験】を大切にする。早く失敗して、予期せぬ驚きの発見や学びを大切にしよう。 この哲学は、TDDの設計の指針であり、TDDにトライしていく指針でもある。 大丈夫、はじめてのことは、きっと失敗する。失敗しないと学べないんだ。小さく早く失敗し、予期せぬ驚きの発見をして、次の一手を考えよう。
試しに、今から、実プロジェクトで2hTDDを１人ひっそりトライしてみよう。。。。2h TDD試してみたかな？ きっと、Red Green Refactorの回転の障害が見つかるだろうが気に病む必要はない。 「あれテスティングフレームワークどれがいいんだろうか？」「インストールは？」「Allテストってどうやって実行するんだろう？」「先にテストを書くって慣れないなー？」「何をテストにかけばいいんだ？」「ついついデバッカー、printの目視で動作確認してしまうよ」「ビルド遅くてRed Green Refactorのリズムできないようー」。。。。etc。 おめでとう！ 今、Red Green Refactorの黄金の回転を妨げる要因を、実験を通じて見つけたのだ。回転を妨げる要因は、ひとつひとつ、落ち着いて対処していこう。 さぁ。Red Green Refactorの奇妙な物語のはじまりだ！。
分類候補
- 上記の学習フィードバック・ループを促進・阻害する観点で分類する候補、個人のスキル、開発環境、ロール間のコミュニケーション、チームとしての仕事の規律
- 時間軸で分類（知らない人が知って、練習し始めて、現場ではじめて、現場で継続して、後輩に伝えて、プロダクトを超えてシェアしていく）
名前ー背景ー課題ー解ー期待結果ーアクションー関連。
期待結果がちょっと文で弱い。