4/9(日)に開催された技術書典2で買ってきた本を読んでいくシリーズ。一覧は技術書典2で入手した本リスト #技術書典。
今回は「TDDってなんだ」。
TDDは死んだのかという2014年の議論を下敷きとして、TDDの持つ意味と期待すべき箇所とそうでないエリアをしっかり捉える視点的な話と、現代的な（外部サービス依存が膨らんで3層アーキテクチャ時代のノリでカバーできなくなっている）テストターゲットへ取り組むPactの入門話をカバーした本です。
あとがきに書かれているとおり、blogや講演録の加筆版ということで、章ごとの内容/主張が微妙に重複する部分があるものの、話の筋は一貫しているので混乱せずに読めます。むしろ、「ああ、前の章で書いていたことを別角度から見たらこのような表現になるんだな」と理解の補強に役立つので良い感じです。
すでに電子書籍版をBOOTHで販売しているので、興味のある方はチェックしてみてください。
TDDとテストファーストは違うという話
- テストによって開発が駆動されること、テストコードが製品コードへフィードバックをもたらすことが大事
- これがとにかく原則で、これを頭から外してしまったら着地点がおかしくなるらしい話だった
- 各ソースファイルに1対1でテストを書くことを目指してはいない
- 開発者テストと品質保証テストは目指すものが違うが相補的なもの、という認識を持っておかないとTDDのテストが持つ意味を見誤る
- テスト書くべきという論展開をする際に、良い開発プロセスを追求する話と道義的に「やるべき」という話を混ぜないこと
- 議論レベルがすっきりと整理されてる
- それに加えて、話として全体的に「雑にくくったら同じことを言ってるように見えるかもしれないけど、持っている意味が違うし 直接的だけでなくて補完的意味合いまで含めて考えるとだいぶ違うのだから、ちゃんとそのへん整理して認識しようね?」という話（この要約自体も割と雑にくくってしまっているので要注意）
仕様のテストと実装のテストの違いの話
- 仕様のテストに寄せることで内部クラスのリファクタにも強いテストを書けるがそれだけで良いのか?という
- 実装のテストを書いたほうが効率的な場面を3つ挙げている
- 挙げられている3点は確かにどれも悩ましい(≒プロジェクト行動上の議論ポイントになる)ところ
- これらを明確に意識してテスト記述水準を検討するのは有用だと感じたし、よりよい開発プロセスを求める行動の一種だな、と読んですっきりした
「不安をテストで表現すること」章
- 最初の章の議論を別の角度から読み解いたもの、に見えた
「なぜテストファーストするのか」章
- とてもシンプルで、テストを成功させることと失敗させることの表裏が重要で、そのためにはまずテストを失敗させることから出発するテストファーストがぴったり都合良いという話
「きれいなコード」章
- きれいなコードとはどのようなコードか
- 著者は、いかに解こうとしている問題のドメインを率直に表現しているか、という視点で見ているという話
- そもそもコードのよさは重要なのか、という視点。そして、この向きよりも現存のコードが現実の周囲にどのような影響を及ぼしているか、どこに進んでいくべきか、と考えるべきではという論
「テストと『品質』」章
Pactで始めるコンシューマー駆動契約
見つけたtypo
基本的にPDF版で読み進めたので、「すいーとみゅーじっく」 vol.1 サポート情報の記載分とは重複していません。
- p.7 「私は読んでいます」→「～呼んでいます」
- p.14「学び取る(Learing)Testing」→「学び取る(Learning)Testing」
- p.14「到達できるかということを差す」→「到達できるかということを指す」
- p.15「洗練されていることででしょうか」→「洗練されていることでしょうか」
- p.18「存在をを前提」→「存在を前提」
- p.23「ruby向け」→「Ruby向け」
- p.23「PactのGithub」→「PactのGitHub」
- p.24「ruby 2.3.3p222」→「Ruby 2.3.3p222」
- p.35「脆い(Fragile) な検証」→「脆い(Fragile) 検証」
最終更新: 2017/07/14 21:59(UTC)