~ my tech diary ~

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てるを読んだ 有名どころの良書なのですが、積読で放置してしまっていたものをようやっと読みました。 事実が変わったときは、私は自分の考え方を変えます。あなたはどうしますか？ ジョン・メイケード・ケインズ TDDにより設計や実装が洗練されてくる話を丁寧に書いています。また、テストコード自体の役割、良いテストコードに関する言及もあります。時刻や外部システムをモックしたり、それらの責務をどのように切り離すか、という話も書いています。 依存性を切り離すこと、テストコードに意味を持たせること、テストコードからテスト対象の関係性を想像できるようにするなど、複数人で開発する上で正しく開発するためのテストに関して言及しています。 テストコードを少なからず書く人は必読な位置付けですね。早い段階で読んだ方が良い感じです。今の段階で読んで、テストコードに意図や実装コードの説明を載せていくとか、そこまで考えることが重要だと改めて感じました。 例えば、処理の順序が大事でないなら、@Afterやexpectationには順序を与えずに独立させて複数メソッドを書き、実行させるとか。setUp()を1つですべての初期化を書くのではなく。 可読性の高いテストコード 何をテストしているのかを理解しやすいタイトル、内容 テストコードの合理化 何を確認しているか(どうやって、よりも、何を) 少ないテストケースで密度の濃いテストが実施できているか 複数のFeatureを1つのテストに含めすぎるのではなく、1つのFeatureのテストを少ないテスト数に凝縮していく、という感じ とかとか。最後のあたりでは、テストをよりよくするためにDBが絡むテストや、非同期、揺らぎのあるテストの話なんかがありました。 依存性注入(dependency injection)をぼんやりとしかわかっていないので、次はそこを学ぼうかな。 そういえば、テストの話でよく テスト自動化を促進するなら、どこから実施しますか？ と聞かれることがあります。その時、テスト自動化のしやすさとか、そういう話はありますが私はずっと 境界となる箇所から始める と答えています。これは、テスト対象の境界が壊れたら、その対象に関係する全てが壊れる可能性があるからです。 昨今、Microservicesと叫ばれたり、Webhooks、Web APIを使って複数サービスを1つの大きなサービスに見立てるという風潮があります。その場合は特に、その境界となる動作が壊れるとすぐさまシステムは壊れることは想像しやすいと思います。そのため、私は境界となるところのテスト自動化から手をつける、と伝えてます。 その考えがこの本でも早い段階で書かれていて、とても共感できました。 ちなみに、GUIを持つアプリだと、人との境目でまずは用意する方がよいかなという立場です。過度な量は無いことは前提です。10分かからないくらい範囲でとか。そのあと、高速なUnit test、Integration test、としていく、という感じでしょうか。SOAやMicroservices的な組織構造を持つチームであれば、Integration testの持つ責任が大きくなるでしょうので、そこは大変だけれど誰かが増やさないといけないですね。Androidだとespressoとかがその位置付けになれると感じています。 iOSはどうだろうか。More