デッドライン読書会第50回（と次の51回）の課題図書は「単体テストの考え方・使い方」です。50回は前半戦で第1章から第6章まで読んでいきます。
前半部分の感想
スコープの章
前半戦のスコープは下記の目次です。
- 第1部: 単体（unit）テストとは？
- 第1章: なぜ、単体テストを行うのか？
- 第2章: 単体テストとは何か？
- 第3章: 単体テストの構造的解析
- 第2部: 単体テストとその価値
- 第4章: 良い単体テストを構成する4本の柱
- 第5章: モックの利用とテストの壊れやすさ
- 第6章: 単体テストの3つの手法
最近はちょっとだけど単体テストを書いている
最近お仕事はSalesforceの開発でプロジェクトマネージャーをしていることもあり、めっきりコーディングをすることは減りました。そもそもSalesforceをプラットフォームにすると、あまりプロコードはないし、少し規模が大きいプロジェクトなので（管理的・人間的って意味の）ソフトな仕事が多いのです。それでもエンジニアメンバーのお手伝いで、簡単なユーティリティや単体テストコードをApexで実装することを少しだけやってます。（月に換算しても数百行程度ですが・・・。）
このApexはSalesforceのプロコードを実装できるプログラミング言語です。オブジェクト指向プログラミング言語で、構文はJavaに似ています。Apexを使えば画面のバックエンドや、データに変更が起きた場合に起動するトリガーなどを設定ベースよりもカスタマイズして実装できます。ただいかんせん構文が古い（？）のと、Salesforceがゆえの制約（仕様）が強いのがなかなか馴染まない感じです。（自分はC#のほうが使う機会は多かったし、最近はPythonばかりだったので）
古典学派とロンドン学派
テスト駆動開発にはざっくりいうと２つ流派があるようですね。本書の2章で言及されていて初めて知りました。私はテスト駆動開発をよく手に取っているので、どうやら古典学派丹所属することになりそうです。ぐぐってみたら、２年前にt-wadaさんがこの２つの学派に言及してました。Twitterスレッドでも展開されているように（本書にも書いてあった）、古典学派のバイブルが「テスト駆動開発」で、ロンドン学派のバイブルが「実践テスト駆動開発」らしい。
この２冊はそもそもちょっと考え方が違ったんだなぁというのが正直な感想です。「実践」がついているからいつかおいおい読もうかなと（仮想的な）積読になっている１冊でした。
3.6 確認（Assert）フェーズの読みやすさの改善
Fulent Assertionの話でした。Assertionを英語と同じ語順にして読みやすくする書き方ですね。こういうの。
// Assert
result.should().Be(30);Apexは標準では `System.assertEquals()` みたいな検証方法しかないんだけど、AppExchangeでいれればFulentAssertといたライブラリもある様子。これはいつか使ってみたい。
語順も英語っぽくできるし、オブジェクトに対する検証もやりやすそうだし、例外もすんなりみれそう。
Fluent.Assert.that('Hello World!')
.length()
.isLessThan(100)
.andThen()
.startsWith('Hello')
.hasLineCount(1)
.contains('World');単体テストの３つの手法
６章で単体テストの３つの手法を紹介。何を確認するかによって３つに分類できるというもの。これまで明確に名前をつけていなかったので参考になる。
- 出力値ベース・テスト（戻り値を確認するテスト）
- 状態ベース・テスト（状態を確認するテスト）
- コミュニケーションベース・テスト（オブジェクト間のやり取りを確認するテスト）
次は後半戦
２月１３日から後半の残り部分を読み進めていきます。
コメント