【学び】テスト駆動開発（SD202203）

[ogakuzuko]

参考リスト

• Software Design 2022年3月号

[ogakuzuko]

自動テストの理想的な状態

テスト対象を実装している本人が、実装とほぼ同タイミングでテストを書き、テストコードの対象範囲が無駄なく漏れ無くカバーされていて、その書かれたテストが頻繁に実行されている状態が、自動テストの理想的な状態。

【📝 コメント】 基本的に自動テスト（テストコード）は実装と同タイミングで書くことによって効果が最大化されるところがある。 これは実際、自分も最近はテストコード書きながら実装することが多くて、その恩恵に大いに肖っているのでとても納得するところ。

[ogakuzuko]

自動テストの効果

テスト対象の理解が深まる 自動テストでは対象のコードが具体的にどう動くべきなのかを記述していくので、テスト対象をより広く深く考えるようになります。具体例を考える過程で、仕様の曖昧さや潜在的な欠陥にも気付きやすくなります。

【📝 コメント】 これは凄いある。個人的に最近やっている取り組みとしてとても良いのは、先に「こうなったらこのタスク(ストーリー)は完了」という受け入れ基準を設定してしまうこと（アジャイル開発）。 テストコードを書いている際にも仕様の漏れ等には気付けるが、テストコードを書く以前の段階で仕様の抜け漏れに気付くことができるという点で先に受け入れを作成しておくのは凄くいいなと思ってる。受け入れを作成しておけば、それをそのままサブタスクにすることもできるので一石二鳥。 受け入れ基準を作成する段階とテストコードを書く段階で仕様に関するダブルチェックの機能を果たせるというのもメリットかも。

受け入れ基準作成 → 開発&テストコード

設計改善のきっかけになる 「テストが書きにくい」というのも大事なフィードバックです。テスト対象が密結合や低凝集という状態になってしまっていることを示唆しているからです。 実装者本人が実装と近いタイミングでテストを書くと設計変更のハードルが下がり、現状の実装に対して無理やりテストを書くのではなく、実装のほうを、テストを書きやすい設計に変更できます。 テストの書きやすい設計とは、 「責務が明確で、結合度が低く(低結合)、凝集度が高く(高凝集)、決定的(deterministic)な動作をする」 という、一般的にソフトウェアが備えていると良い性質を持った設計ということです。

【📝 コメント】 まだテストが書きにくいなあという実体験を持ったことはないけれど、この視点は重要だなと思った。 テストが書きにくいということは適切に責務を分割してコードが書けておらず、テストを書きやすくするような工夫（例えばDIなど）が行われていないということ。確かに、テストの書きにくさは設計改善のチャンスだな。

[ogakuzuko]

テストファーストの効果

テストファーストとは、その名の通り、実装よりもテストを先に書くプラクティスのことです。

【📝 NOTE】 実装よりも先にテストを書くのを「テスト駆動開発」というのだと思っていたのだけど、これは違うのかな？

インターフェースと実装を分けて考えられる テストファーストでは「それは何か、どうあるべきか」から考えて、次に「それをどう作るか」を考えるという順番になります。人によってはそれを振る舞い、仕様、仮説などと表現します。 インターフェースと実装を分けて考えるのが設計では非常に大事ですが、テストファーストでは実装がそもそも存在しないので、自然とインターフェースから考えることができます。

【📝 NOTE】 おお、なるほど確かに、これはメリットかも。 インターフェースを先に意識せざるを得なくなるっていうのは大きいね。インターフェースの綺麗さはそのまま実装の綺麗さに直結しそうだし。