テスト駆動開発をざっくり読んでみた
最初に
テスト駆動開発を読んでいる際に、個人的につけていたメモです。
いわゆるまとめ記事ではなく、内容も飛び飛びで読んだときの自分の感想がメインの記事となっています。
とっ散らかった文章ですが、参考になれば。
本の感想ですが、TDDの原典にやっとこさ触れることができうれしかったです。著名なほかの本と関連付けながら楽しく読めました。
第1部 他国通貨
動く⇒きれいに
まず実装後の挙動を示すテストを実装し、テストがパスしないことを確認する。その後どうにかしてグリーンにして、安心してから重複を取り除く。
これがRed ⇒ Green ⇒ Refactoringのサイクルとなっている。
なお、重複とは、依存性の問題を抱えるているコードに徐々に発現するものであることから、TDDの方針である「重複を取り除く」とは、コードに潜む依存性を繰り返し取り除こうと努力することを指しているのだろう。
まずは失敗しているテストがPASSできるように実装をする。実装したコードを見て感じた違和感や重複の可能性があれば、それを確認するためのテストコードを書いて確認したのちに、改善するためのリファクタリングをおこなうというサイクルをひたすらに回し続ける。この「感情をテストコードに翻訳する」というのがとても大事だと感じた。違和感といった感情を持てるかどうかは、コードスメルを嗅ぎ分けられるかどうかと似ているとも思った。
また、greenにするためには一時的な重複を許容できるが、その時に罪を犯しているという感覚を覚えておくことを忘れないでおきたい。本の中だとそういった違和感や感覚をメモする先としてTodoリストが使われていた。
歩幅を常に調整
TDDを進めていく中で、どれだけ細かくステップを重ねていきながら進めていくのが適切かは状況によって異なるため、一概に政界の歩幅は存在しない。
重要なのは歩幅をコントロールできるという事実にある。テストがあるから、歩幅を自由に伸び縮みさせることができるのだ。
仮に歩幅が大きすぎたり、間違った方向に行きかけてREDが常に出てしまう場合は巻き戻してから再度歩幅を調整していく。
まるで塹壕を掘って徐々に進んでいく感じに近いなぁと思った。歩幅を刻みながら重複を見つけたら削る、を繰り返すことでどんどんテストコードがきれいになっていくのだ。
綺麗なコードは突然ひらめきを具現化する助けとなりうる。12、13章で結構レベル的にジャンプした感じがして、歯ごたえがあったので繰り返し読んで理解したい。
テストコードをメモ帳的に使う
テストを書いてから実装する、というのがTDDの基本的な思想であるが、大事なのはテストコードの実装を先にする、というところではなくて、考えていることややりたいことをメモしたり確認するための位置付けとしてテストコードという技術を使うというところが一番のキモかもしれないとしばらく読んで感じた。Red⇒Green⇒Refactoringのサイクルを回すことが重要であるが、まずRedをどうにかして書くというところがキモであり、逆にいうとハードルの高さでもあるのかも。
テストコードは、テスト対象のコードの品質担保のためだけではない。バグを再現するため、コードがどのような振る舞いをするかを確認するため、自分の中の理想形を具現化するため。どれも最終的に内部品質を高めるためのテストコードとして活きてくるのは前提として、もっとカジュアルにテストコードを書いても良いのだと思わせてくれた時点でこの本を読んだ価値があると思った。
テストのカバレッジ
テストコードのカバレッジの総量は、プログラムをあらゆる側面でテストしたテストコードを、テストする側面の数で割ったものになる。
よって、カバレッジを上げるためには、テストコードを増やすか、テストするコード自体を減らすことが手段としてとれる。
プロダクトコードの方をシンプルできれいなものに作り替えることで自然とカバレッジも上がっていくということであり、きれいにする作業はリファクタリングそのものとも言えそう。
第Ⅱ部 xUnit
今の自分にはレベルが高すぎたのと、ほしいところとはちょっと外れていたので流し読みしてしまった。。。
というのも、自分がテスト用のフレームワークがあふれている時代でプログラミングをできているのは先人たちの試行錯誤の上なのだな～とつくづく思う。
第Ⅲ部 テスト駆動開発のパターン
テストを書きやすい実装は良い実装
良いテストとは、直行性を持っており、テストの実行結果がたがいに影響を与えない独立した状態となっている。
独立したテストを書くためにはテスト対象の実装も直行性を持っている状態である必要がありこれがいわゆる「テストしやすいコード」ということになる。
独立したテストを書くためにを考えた結果、おのずと良い設計になっていくという話の原典を読めてうれしかった。
仮実装によるスコープの制御
Red⇒Green⇒Refactoringの中で、どうにかしてGreenにいったん持っていく実装を「仮実装」と呼んでいるが、これは問題解決の方法を抽象化してとらえるための具体例をコードとして具現化することが種の目的となる。
いきなり抽象概念を扱うよりも、ひとつ具体例を作ってそこから抽象に挙げるほうが脳の使い方として楽というのは、プログラミングだけでないかもなと思った。
何度も書いているが、TDDは一発できれいにするのではなくて、歩幅を自分で調節して「徐々に、だけれども確実に」コードをきれいにするに長けている方法である。
どこまでテストを書くべきか
以下の部分が良すぎた。最近テストケースを考えていて、同地分割法や境界値分析を使ってテストケースを充実させることは可能だが、どこまでやるのが正解なのかいまいち判断がついていなかったので「自信がつくまで」というのは指針としてあいまいなようで至極全うだと思った。リファクタリングといっても、コメントを修正するレベルなのか、条件分岐をいじるぐらいやるのか、その程度によって実装すべきテストの数は容易に変化する。
Discussion