「JUnit イン アクション」読了！

結構前（3ヶ月以上かもっと前？）に読んでたけど、振り返りをしていなかったので。

自分は本を読むスピードが遅くて1ヶ月に何冊も本を読むことはできないのですが、その分こうやって振り返りはちゃんとやろうと思ってます。結構時間もかかるのですが、一度読んだのを後でもう一度読み返すのは結構ためになるんですよね。読んだときに思ったことと振り返りのときに思ったことが違ってたりすると特に。

JUnitイン・アクション

---

第1章 JUnitの概要

1-1 動作の検証

結構古い本だけど、品質保障テスト・カスタマーテストと一緒にプログラマテスト（ディベロッパーテスト）について触れています。

また、各種テストについても最初に定義しています。テストって範囲が広いので、ここぶれると話がまったく噛み合わなくなりますからね。

単体テスト

1つの「作業単位」の振る舞いを検査します。Javaアプリケーション内部では、多くの場合1つのメソッドを指します。

統合テスト・受入テスト

様々なコンポーネントの相互作用を検査します。

第4章 ソフトウェアのテスト

4-2 さまざま種類のテスト

この章では、単体テストをさらに下記の3つに分類しています。単体テストと言っても、どこまでを指すのかはまた議論の余地があるんで、こういう定義は頭を整理するのにいいですね。と言いつつ、統合単体テストと機能単体テストをうまく説明できるほど整理がついていませんが。。。

単体テストの種類	説明
ロジック	コードのロジックの実行に焦点を合わせた単体テスト。 メソッドの境界はモックオブジェクトやスタブで制御できる。
統合	実際の環境（またはその一部）でのコンポーネント間のやりとりに焦点を合わせた単体テスト。
機能	統合単体テストを刺激/反応が確認できる範囲に広げた単体テスト。

• 参考：ソフトウェアテスト | 634Labs

ロジック単体テストは、メソッド単体で簡潔するレベルでのテスト。機能単体テストは、アプリケーションから見て一纏まりの流れを切りだしてテストしたものと言えるかな。例であげられているのは、「Webアプリで未ログイン時に認証エラーを出す」という機能に対して、「HTTPリクエストを投げて401が返ってくること」をテストするというのがあげられています。中間の統合単体テストは、アプリケーションから見ると一纏まりにはなっていないけれど、別コンポーネントとやりとりするテスト。例えば、「データベースにアクセスするコードで、データベースを効果的に呼び出すテストを使用して、コードとデータベース間のやりとりがうまくいくことを検証する」と定義されています。

ロジックレベルはできる限りテストするということでいいとしても、統合・機能レベルはフレームワークのサポートがないと難しいところもあるかと思います。時間がかかる（スローテスト）こともネックですね。この問題に対しては、CIをうまく活用して自動でテストを流すというのが一つの解だとは思ってます。

---

あれ、思ったより振り返りの材料少ない。読書の最中にもっとメモはしてましたけど、何かうまくまとめられる項目は少なかったみたいです。多分経験不足だから。

この本に書かれていたことを常に意識する、というのは現実問題難しいかもしれないけど、頭の片隅にでも入れておけば今後の指針として役に立つことでしょう。多分。