はじめに
お休みは映画館でミリアニ見るぞ〜、nikkieです。
ちょうぜつ本のテスト駆動開発の章の前半1を読み、「ここらで積ん読を消化するか」とテスト駆動開発に関するt-wadaさんの過去の連載をまとめ読みしました。
合わせ読みも狙っています。
目次
- はじめに
- 目次
- 和田卓人の“テスト駆動開発”講座
- 誰のためのテスト？
- テスト駆動開発のリズムを学ぶ
- 資産価値が同じ大きいテストがあるので、小さいテストを捨てる
- 終わりに
- P.S. なぜこの古い連載を知っていたのか
和田卓人の“テスト駆動開発”講座
私はまだ見られていませんが、ニコニコ動画にも映像コンテンツがあるそうです。
第1回の連載ロードマップによると
- 12回までが講義編
- 13回〜20回がディスカッション編
今回は講義編をばーっと読みました。
印象的だった点をログに残します。
誰のためのテスト？
ユニットテスト、単体テスト、機能テスト、結合テスト、受け入れテストの分類についての解説です。
t-wadaさんは目的別の分類を提案します。
何のためのテストかという視点によって、Developer Testing、Customer Testing、QA Testingの3つに分けましょう
「誰が、何のために、誰のために」行うのかという視点で、錯綜してしまったテスト分類を見直してみましょう
引用に出てきた3つは第3回で解説されます。
- テスト駆動開発の"テスト"はDeveloper Testing
開発を前に進める「原動力」
- Customer Testing：顧客から見て機能がどれくらい出来上がっているかを示す2
- QA Testing：品質保証
t-wadaさんによるナントカテストの目的別の分類ですが3、
- 単体テスト・ユニットテスト：Developer Testing
- 開発者自身が開発者自身のために行うテスト
- 結合テスト・機能テスト：Developer Testing
- 開発者自身が開発者自身のために行う
- 受け入れテスト：Customer Testing
- 顧客に機能がどれくらい出来上がっているかを示す
プロジェクトのためのテスト
テスト駆動開発のテストは開発者のためというのは知っていたことではありますが、「誰が」や「誰のために」を考える目的別の分類でナントカテストが整理された感覚があります。
テスト駆動開発のリズムを学ぶ
テスト駆動開発の学び方として、写経以外にリズムも学ぼうと指南されます。
写経では得られない典型的なものの一つが、「リズム」なんですね。
(略) 一連のサイクルを、30秒で一周回すのか、はたまた2分で一周回すのか。そのような時間感覚は写経ではつかめません。
この「リズム」、私の印象に残っているのは『Clean Craftsmanship』ですね。
30秒やそれよりも短い時間で一周回すということを思い知りました4。
リズムを知るための教材としては『Clean Craftsmanship』の購入者特典の動画や、t-wadaさんによる「TDD Boot Camp 2020 Online #1」のライブコーディングが浮かびました。
https://www.youtube.com/live/Q-FJ3XmFlT8?si=NIyhfRsMG1C5O1PK
資産価値が同じ大きいテストがあるので、小さいテストを捨てる
テストの資産価値は初めて聞いた話で、学びが大きかったです。
小さいテストを全部足した価値と、それらを包含する大きいテスト1個の価値は同じだと考えているのです。
小さいテスト、大きいテストというのは第9回のサイクルの話。
「レッド、グリーンのサイクルも自己相似」の図を引用します。
https://gihyo.jp/assets/images/dev/serial/01/tdd/0009/thumb/TH800_01.png
この図の理解
- 下側にある赤と緑のサイクルが小さいテスト
- 小さなテストいくつかの総和で、その上にある大きなテストが通る（上側の大きな赤と緑のサイクル）
ここで、下側の複数の赤と緑のサイクルと、その上にある1つの大きな赤と緑のサイクルは同じ資産価値！
「新機能をテスト駆動で開発するところで活躍してくれたテストだけど、そういう小さいテストたちは今やもう役目を終えたので、メンテナンス対象から外してしまいましょう。消してしまいましょう」
モックを使ったテスト5を書くと、第11回で扱われているように一度にたくさんのテストが落ちることがあります。
これまでの私は1つ1つ直していたのですが、今回連載を読んで資産価値が同じだから小さいテストたちを消すという方法も選択していきたいと強く思いました。
『Googleのソフトウェアエンジニアリング』のテストの章を読んで、「脆いテストを防ぐ、これってどうやるんだ」と引っかかっていました6（だって、一度にたくさんテストが落ちるのが私にとっては普通なんですよ）。
これを実現する1つの方法は、小さいテストを消すことと示唆を得ました。
終わりに
「和田卓人の“テスト駆動開発”講座」の講座編の読書ログでした。
私にとっての大きな学びは2つです。
- テストの目的別の分類
- 小さいテストを捨てる
特に後者はソフトウェア開発で引っかかっていた点（脆いテストを防ぐ）に示唆を与えてくれました。
こんまりしていくぞ〜🦁✨
こちらの連載は、ちょうぜつ本のテスト駆動開発の章とは相性がよいように感じています。
ちょうぜつ本で登場した単体テストやモックについては別の説明が聞けましたし、ちょうぜつ本でテスト駆動開発を学んだ後もt-wadaさんの連載には立ち戻りたいなと思っています。
P.S. なぜこの古い連載を知っていたのか
DjangoCongress JP 2018のtell-kさんのトーク「できる！Djangoでテスト!」がきっかけです。
「Developer Testing」はスライドに登場しており、参考リンクからt-wadaさんの連載を知ったのでした。
そうそう、DjangoCongress JP 2023はトークが出揃ったようですよ！
トーク・発表者の一覧が公開されました！今年も興味深い内容が盛りだくさんで、初心者の人から業務でバリバリの人までぜひお越しください #djangocongress https://t.co/7bF54ZrYZ0
— django-ja (@django_ja) 2023年9月1日
