2024/8/14
laprasdrum.icon 週末台風らしい🌀
/icons/hr.icon
TDDの定義の希薄化
Kent BeckがSubstackに投稿した記事をid:t-wadaが翻訳したもの。
ステップ1. テストリスト
TDDの最初のステップは、あるシステムに振る舞いの変更が望まれているとき、その新しい振る舞いにおいて期待される動作をリストアップすることだ。「正常系はこうで、もしもサービスがタイムアウトしたらこうして、データベースにキーがまだないときはこうする。あとは……」
これは分析(analysis)だと言えるだろう。なかでも振る舞いの分析にあたる。変更後の振る舞いが満たすべき様々な動作を網羅的に考えよう。振る舞いの変更が既存の動作を壊さないようにする方法を考えているなら、それもテストリストに追加する。
よくある過ち: 実装の設計判断を混ぜ込んでしまうこと。まあ落ち着こう。内部実装がどうあるべきか吟味する時間は後からいくらでも確保できる。目の前のことだけに集中すれば、テストのリストアップがもっと上手く進むようになる(紙ナプキンに実装のスケッチをする必要があるならば、やってみてほしい。でも、それはたぶん必要ない。まあ試してみるのは止めないが)。
多くの人が、書籍『テスト駆動開発』の中に出てくるこのステップ1を見逃しているようだ。「TDDはいきなりコードを書き始める。いつ終わるのかも全然見通せない」という意見は、全くの見当外れだ。
自分もテストコードの記述(記事中で言うDeveloper Test)を始めたての頃はこのステップ1が抜けてた。
急に書き始めてあとからテストリストを作ろうとしても、(よくある過ちに指摘されてるように)内部実装に囚われたテストケースを列挙しがち。
まずは落ち着いてビジネス要求を整理してソフトウェア仕様に言語化することが大事。
学習の過程で成功のアウトプットの裏には数多の失敗がある
Second, you have no idea how many mistakes I've made over the years. Lots of small ones, sure, but dozens – hundreds? – of really serious errors, some of which I'm going to regret to the end of my days.
Anyway, I'll leave you with this: keep making mistakes, remember that it's better to regret the things you have done rather than the things you haven't, and don't try to compare yourself to me – trust me, if there were a Screw Up Olympics I'd get a gold medal!
一発で成功し続けてる人生を送ってる人を見たこと無いし、どんどん失敗すべき。