-
Notifications
You must be signed in to change notification settings - Fork 49
Readingagilesamuraiinsapporo20120410
irasally edited this page Apr 10, 2012
·
5 revisions
- 2012年04月10日 19:30-21:00
- エスプランニング開発室
- 参加者 6人
- 第12章
- この例示はあまり好きではないなあ
- どのあたりが？
- ブラックジャックのデッキにジョーカーが必要かどうかってユニットテストレベルと言うよりはドメインレベルの知識じゃないかな
- テストの観点からすると、例としてはちょっと違うかな、と思った
- 文脈としては「1回直したのにまたバグが埋め込まれた」という例 という風に読む必要があるね
- リグレッションテストの必要性を示したいんじゃないかな
- ジョーカーの有無よりも全体で1枚足りなかった、という例のほうがこの文脈だとしっくりくるかもしれないね
- どのあたりが？
- P237 "プロダクトに重大なバグが発見されたことを知らせる、感じの悪いメールが〜届いた。昨晩、プロダクトに重大なバグが発見されたというのだ"
- 大事な事だから「プロダクトに重大なバグが発見された」と2回書いてある？
- 原著：Then a couple weeks later you get a nasty email from the QA manager informing you that there was a major bug in production last night. -> 繰り返されてはいない
- 出してみました：https://github.com/agile-samurai-ja/support/issues/25
- バグを修正する前に、失敗するテストを書くということ（コラム）
- テストでバグを再現させてから直すのは大切だね
- 最短のロジックで再現させられることではじめて、バグの本質を理解したことになると思う
- きのこ本では和田さんがこのことについて書いていたね
- バグの原因追及と同時に、「他が壊れないことの確認」も大事
- リグレッションテストの重要性
- ユニットテストってどこまでを言うのかな？
- レガシーコード改善ガイドでは「0.1秒以上かかるのはユニットテストではない」と書いてある
- 結合テスト（他のモジュールと関連しているテスト）はユニットテストとは別のものであると考えている場合はそうなるね
- 目的で分類したりもするよ（ユーザーの最終受け入れテストだけを分ける）
- この本では"メソッド単位で書く小さいテスト"と定義されているね
- 大きなユニットテスト、小さなユニットテスト、ユーザー受け入れテスト、という分け方をしていることもあるよ
- レガシーコード改善ガイドでは「0.1秒以上かかるのはユニットテストではない」と書いてある
- "バグを再現する"となると結構大きな単位（メソッド以上）でのテストを書いて再現させることもあるんじゃないかな
- 再現するためのテストコードが大きくなると管理コストが結構かかるんじゃないかな
- 現実的には結構難しいことが多いのでは？どれくらい時間をかけられるかはケースバイケースだよね
- 再現してピンポイントで修正できるといいのだけど、全てのバグがそうはならない
- あまりに大きな手順であれば絞り込む段階でのテストは書かなくても良いのではないかな（癌になる部分だけテストを書く）
- 再現するためのテストコードが大きくなると管理コストが結構かかるんじゃないかな
- バグを再現させるときに2つの方向性があることを意識すると良いよ
- ある程度不具合原因の当たりが付いたバグは最初にピンポイントでテストを書いて直せば良い（内から攻める）
- どこが原因かわからない場合は再現するテストを書いて1箇所づつ掘り下げながら原因箇所を探していく必要がある（外から攻める）
- メンテナンスの観点からどちらのソースコードを残すのだろう（1メソッドのユニットテスト、ストーリーテスト）
- 1メソッドのユニットテスト：設計書の側面から、設計が終われば捨てても良いという考えの人もいる
- ストーリーテスト：最終的なストーリーが書かれているものだから、メンテナンスして残しておく必要があるとする人が多い
- その側面で考えるとそうだね
- 理屈と現実の壁
- いつも、必ず、しっかりテストがかけているかと言うと時間の関係で諦めることも多い
- アジャイルなプラクティスを導入する順番の話
- この本ではユニットテスト->リファクタリング->TDD->CIの順で紹介されているね
- 現場によってはCIから初めてもうまく行くことがあるよ（土台を固めて後からテストを増やして育てていく）
- 初めての人が学んでいきやすい流れだったりする
- TDDは最後の砦。
- テストでバグを再現させてから直すのは大切だね
- 「全てのテストを完璧にはできない」ということを認めることが大事
- 個人や開発者だけでなくチームで認めること
- テストが完璧でなかったことを失敗としてむやみに責めなくても良いと思うよ
- 大事なところだけテストを書くことからはじめてみるのがよいね
- テストのメリット
- デバッグ時間の削減は状況によりけり（時間の削減の助けにならない場合もある）
- 状態を大量に持っているオブジェクトのテストやデバッグとか
- 本質的に複雑なものはプログラムも複雑になってしかるべきなんだよね
- 良い事例となるバグに出会うことってなかなかないよね
- 生きた例（テストのアプローチやリファクタリング）をもっと学べたら良いな
- デバッグ時間の削減は状況によりけり（時間の削減の助けにならない場合もある）
- 「ほとんどの場合はオブジェクトの生成と、メソッドを呼び出した結果に対するアサーションで対応できる」 これ、ほんと？
- 実際は単純なものは少ないよね
- Mockは基本的に必要になるよね
- GUIのテストとか・・・
- ユニットテストは「防具」という例えを使われることが多いのだけど「武器」という側面もあるという話もある
- リファクタリングでレガシーコードを「攻める」ためにソースコードがある
- そういう考えでいたいなあ
- 攻めるほうが目的がはっきりしている
- 防具だと数が多ければ多いほどいい -> 防具が重くなることがある
- 不安を切り捨てるための武器という考え方は良いね
- レガシーコード改善ガイド[本]
- レガシーコードを改善するためのテストはソースコードとして一時的におかしくなるかもしれないけどそれでよい、と書かれているのに感銘をうけたよ
- Agile Samurai Dojo Gatheringでジョナサンが話していた「この7冊を1つにしたかった」というアジャイル関係の本の紹介
- 今までの読書会でも話が出ていた本が多いねー
- ユニットテスト ＝ 自動化なのか？
- ユニットテストというタイトルで始まっている章なのに最後の方には「自動化」のことだけ書かれているのが気になったよ
- ユニットテストは自動化ありきが多いよね、基本的にほぼイコールとなるはず
- CIより前のレベル、個々のマシンの中での自動化の話
- 自動化の目的
- 再実行できる
- 手順を間違えない
- 誰がやっても同じ結果になる
- 時間などのコスト短縮
- ブラックジャックのテスト
- 52枚全部テストするのか？！
- まぁ、例だから・・・
- 242ページのカードの裏に書いたことはお客さんに見せるのかな？
- この粒度では見せないだろうなあ
- ジョーカーとか枚数はドメインレベル（ヘタをすれば常識）だから事前に共通認識をもっているんじゃないかな
- このカードに書かれている内容はTDDをする時のゴールの粒度と同じくらいだね
- テストの網羅性は重視すべきではない
- カバレッジ100%要求問題
- ではどのくらい達成すればいいのか？の答えは => チームで決める
- 「あぶなっかしいところを全てテストする」
- 平均的には8割か9割になっていることが多いよ
- テスト対象をどこにするかというテスト戦略の問題もあるよね
- この本で書いてあることは、イテレーションがずっと続けていくのが前提
- イテレーションを重ねていくことで改善していくのがよいよ、というメッセージが込められている気がする
- カバレッジはソースコードばかりではない
- ユースケースのカバレッジという切り口もある
- 必要に十分である状態が望ましいよね
- ユニットテストを書いておくことでプロジェクトの後半が楽になる実感はあるよ
- 不安を保証するものがテストであるという感覚はあるなあ
- ただしその分前半から負荷はかかる（前半からやることがてんこもりの代わりにきれいに収束することが多いよ）
- リリース直前にバグがたくさん出て慌てる、燃える、という状況は減ってきた気がするよ
- 実際にテストを書くコスト（環境や言語、スキルによって）がかかりすぎて諦めたことがあるよ(ObjectiveC)
- 息をするようにテストがかける環境（環境とスキル両方）って大事だよね
- テストを書くまで、テストを実行するまでに技術的・環境的な壁があるとテストを書かなくなってしまう
- テストコードを書かないとリファクタリングができないってところは重要だよね
次回は4月24日（火）19:30- です!!