テストを設計ツールとして使おう！ #TDD
♪今年のブクマ、今年のう・ち・に！
というわけで、長いことほったらかしにしてたブクマの中から
気になるやつをピックアップ。
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
う～、タイトルが長い。中身も長い。
長いと最後まで集中力が続かず、ついついほったらかしになるのよネ。
そもそも CodeIQ のしくみも知らなくて、設問に対する解説の形式だってのにも気づいてなかったわ。
さて、読んでみると、出題者の和田卓人さんがていねいな解答とともに大事なことを
[ポイント]という部分で解説して下さっています。
そして最後に「テストコードのポイント」としてその[ポイント]の部分を列挙してまとめて下さっていました。
きれいにまとまっていますので、引用させて頂きます。
良いユニットテストは Repeatable (繰り返し可能、再現可能)
- テストダブルを使いこなす
- 外部環境との界面にインターフェイスを作成し、テストダブルで置き換える
良いユニットテストは独立 (Independent) していなければならない
- 後始末を忘れずに行い、テストを独立させる
- static を避け、テストメソッド間の依存関係を断つ
Assertion Roulette に注意する
Fragile Test (脆いテスト) に注意する
- テストだけに使う部分の可視性を下げる
- private メソッドを扱いたくなったら要注意
テストを設計ツールとして使う
- テストコードのノイズを減らす
- 日本語テストメソッドを試してみる
- シンプルなコードとテスト失敗時の情報のバランスを考える
（引用ここまで）
私の気に入ったのは最後のポイントのところ。
全文引用させて頂きます！
[ポイント] テストを設計ツールとして使う
テストを書くと、必要十分な設計に気づきやすくなります。
設計は終わりのない世界です。そして、設計について考えすぎると、終わりがない世界に踏み込んでいることに気づきにくくなります。このようなとき、テストの結果/ゴール/具体例から考えることで「あれもできる、これもできるかも、ああいうやりかたもあるな」というフワフワとした状態から、ピントのあった状態に戻ることができます。
テストコードと共に設計/実装を行うと、コードを書くことや、書いたコードをすぐ使うことから、設計に対するフィードバックが発生します。実際にテストとコードを書くことによって、設計だけしていたときは考え過ぎていて、もっとシンプルで良いことがわかったり、または逆に設計時だけでは考えが足りておらず、実際にコードを書いたり具体的な値でテストするようになって考慮不足がわかる、という状況によく出会います。
テストを書くことは、終わりのない設計の世界から現実に戻ってくるきっかけのひとつになります。良い設計は状況によって変わります。必要十分でシンプルな設計から、次のシンプルな設計へと不安なく移るために、テストを活用してください。
（引用ここまで）
そうなのです。早くフィードバックを得て、迷いの時間を減らすことも大事なことです。
やっぱ、TDD って設計だよね、と思いました。
こういう実感はこういう視点を持ちながら作業しないと気づきにくいことなのかもしれません。
だから、プログラムを書くひとは、常に自分が設計者であることを意識してほしいと思います。
ではまた。
