『単体テストの考え方/使い方』を読んだ
単体テストの考え方/使い方
著者：Valdimir Khorikov
訳：須田智之
この本で得られること
この本は、1~3章でユニットテスト（単体テスト）の概要や基本的な考え方、よいユニットテスト、悪いユニットテストの知識を得ることができる。
4~7章では、簡単なユーザー登録のプロダクションコードの例を挙げ、それを解説しながら少しずつリファクタリングしていく。ここで、良いプロダクションコードの設計と、それに対するテストコードの方針、どのように書くかを学ぶことができる。
8~10章では、統合テスト（結合テスト）の考え方、書き方、モックの使い方を学ぶことができる。DBの取り扱いやログのテストをどうするかも悩んだことがあるエンジニアは多いと思うが、そこも言及されている。
11章ではユニットテストのアンチパターンが記載されている。ただ、これまでの章で様々言われていることの、言い方を変えてまとめた内容になっているように感じられる。
中心となる4~10章で、具体的なプロダクションコードを例に、それを良い形にリファクタリングしながら、それに対するテストを書いていく、という部分がとてもわかりやすい。
言語はC#だが、わかりやすいのでコードを書いている人なら特に問題なく読める。
この章では、以下の良いユニットテストを構成する4本の柱で語られているということだけ挙げておく。
退行（リグレッション）に対する保護
リファクタリングへの耐性
迅速なフィードバック
保守のしやすさ
読んだ方がいい人
エンジニアであれば一読する価値がある。
ユニットテストは書いたほうがいいのはわかるけど、どうやればいいかわからない。
テストコードを書こうとした人ならこの壁にぶつかった人は多いと勝手に想像する。
私はそのような状態だったし、あまりユニットテストについて聞く機会もなかった。Quality Assuranceの人に聞いてもテストがどうあればいいかではなくブランチカバレッジの話が出る程度だった（網羅率の神話もこの本で語られている）
この本を読むことで、体系的なユニットテスト・統合テストの知識が得られるし、良いプロダクションコードの設計、良いテストとは、という、今まで雲をつかむような部分だったところがはっきりとする。
また、品質保証業務を担当する人（QAエンジニア、テストエンジニア）も読んでみるとよいだろう。
ただコードを書く人を前提として書かれているので読みにくいかもしれない。その時は1~4章と、各章のまとめを読むと良い。
開発全体的な品質について知っておくのであれば価値がある。
先述したが良いテストコードのあり方を聞いても、網羅率（カバレッジ）の話で止まってしまう。この本では、以下のように記載されている。
網羅率の値に縛られることはソフトウェア開発において害となることである。システムの核となる部分に対して高い網羅率を出せることは良いことだが、そのことを強制することは開発の妨げとなる。
簡単に読みたいなら
この本は400ページ近くある。
読むのが大変なので、もし簡単に読みたい人、または立ち読みで内容を確認したい人は、各章の「まとめ」を読むのがよいだろう。
各章2ページ程度の内容にまとめられている。
感想
私が直近で担当したゲームアプリは、ユニットテストを書かない人が多かった（書く人は書くが要件ではない）。トップの方針が、品質はさておき早く出せ、だったからだ。
最初何とかローンチできたが、その後アジャイルで回してリリースするのだが、回を重ねるたびにボロボロになっていく。どんどん追加開発、保守しにくくなっていく。リリース前に予想外のところが壊れていてリリースを遅らせる、リリースができないはまだましで、リリースした後に、誰かがコピペしたコードが壊れていることに気づかず大きなバグが発生することもあった。だからといって、テストコードをどう書けばいいかは経験則であり、よくはわかっていなかった。（中国メンバーの拒絶反応もすごかった）
さらに前にいた現場では、昔からあるシステムでユニットテストも必要な場所だった。そこはプロダクションコードとテストコードが密結合になっている場合が多く、少しリファクタリングするとプロダクションコード自体の振る舞いは正しいがテスト側がうまく動いておらずよくエラーを吐いていた。エラーを吐くことに慣れすぎてしまって、エラーを確認せずリリースし本当に問題だった時に本番障害を起こしている場面にも出くわした。これもリファクタリングに耐性があるテストの書き方がよくわからなかったことに起因していたと今は思う。
そんな私からするとこの「単体テストの考え方/使い方」は有益な書籍であった。
テストを書いた方がいいことはよく言われているし私もそう思ってはいたのだが、どう考えどう適用するかがいまいちわからなかった。
それが全体的に分かったこと、自分の中に方針ができたことが何よりも良かった。
またプロダクションコードをどのようにしていったほうがよいかも多くのページを割いて書かれていて、読んで把握したつもりではいる。
結局は設計が良くわかりやすい、テストしやすいプロダクションコードが継続的にリリースしやすいコードなのだ。
この本を読んだことで、どのような方針、設計でプロダクションコードとテストコードを書けばよいか頭ではわかった。
この手の本で大切なのは実践で活かせるかだ。
少しずつ、本の内容を試していきたい。
この記事が気に入ったらサポートをしてみませんか？