TDDの基本サイクルと足し算の例
ITエンジニアの雑談駆動開発部。
この番組は、同い年、若手エンジニア2人が、技術のこと、キャリアのことを、等身大のまま語っていく番組です。
成長中の2人が、学んだことをリアルタイムでお届けします。
授業書なし、テストなし、雑談だけで駆動していきます。
ITエンジニアの雑談駆動開発部、始まります!
ということで、私の名前はNAKANOです。
はい、NAKANOさん、よろしくお願いします。
はい、KANOさん、よろしくお願いします。
はい、私の名前はKANOです。
はい、今回のテーマは、TDDです。
TDD?
TDD。
えー、初めて聞いた。
テスト駆動開発。
あ、それは聞いたことある。
テストデベロップメント、テストドリブンデベロップメントです。
テストドリブンデベロップメント。
確か。聞いたことはありますか?
なんとなく、テスト駆動開発っていうのは聞いたことあるんですけど。
どんなイメージですか?
あれですよね。テストをめっちゃやって、担保するみたいなイメージ。
あー、担保する。いいキーワードですね。
ありがとうございます。
なんかテスト先に書いて、やっていくのかなみたいな感じ。
簡単に言ったら。
自分が言いたかったのは、テストを先に書くやつくらいの認識って言いたかった。
ちょっとやりすぎか。
まあ、これはいいですよ。それはもう、これがリアルなんで。
単体テスト好きですか?
嫌い、大事っていうのはわかってるから、神経を使うじゃないですか。
バグが動くから。
だから、大事なのはわかってるからこそ神経使うのに、全然面白くない。
面白くないですよね。
僕もそう思ってました。
一緒ですね。
最初、実装してできたみたいな。
じゃあ、プロリーグ出そうって。
したいんだけど、みたいな。
出した時に、あれ?テストしてんじゃん。
テスト足りてない、カバレッジ足りてないんだけど。
なんだこれ、みたいな。
言われるんですよね。
だるいと思うじゃないですか。
今回は、単体テストが大好きになっちゃう。
聞きたい。
テストラブになっちゃう。
聞きたい。
そういうことを、喋っていきます。
実装だけしていたい、みたいな人は絶対聞かなきゃですね。
気づいたら、テスト大好きになっちゃうんです。
めっちゃいいじゃないですか。
これが今回のテーマです。
聞きたい。
じゃあ、進んでいきたいと思います。
まずは、TDD、テスト複合開発って何なのかっていうのを、
簡単なサイクルで紹介すると、
まず、実装したい機能があるっていうときに、
①テストを書きます。
そのテストを走らせて、失敗することを確認します。
まずテストを書いて失敗させる。
その後、テストを通すような実装を書きます。
その後にリファクタリングをするんです。
イメージで言うと、足し算しよう、みたいな。
足し算したいな。
足し算を作りたいときに、
足し算のプログラムを作る。
って書いたら、
なんとかA足すBを書くじゃないですか。
最初に、この足し算プログラムを動かしたら、
答えが5になるみたいな。
テストを先に書くんです。
このテスト、足し算関数を動かすと、
5になるっていうテストがあって、
それを動かしたら、
失敗するじゃないですか。
何も書いてないから、まず。
その処理自体がないから。
足し算っていう関数がもうないから。
5にならない、失敗みたいな。
2、3を足したら、
5になるっていうテストだけ書いてるけど、
足すやつがないみたいな。
そう、足すやつがない。
それをまず書く。これが第一ステップ。
その後に、テストを走らせて失敗したのを確認しました。
で、テストを通します。
足し算関数、a-b。
テストを動かす。通りました。
嬉しい。
これは簡単なことなんで、これ。
簡単な実装をまず例で言ったんだけど、
これが一個のサイクルみたいな。
そう、これをサイクルにしていく。
でもなんか、分かるかもしれない。
なんか、できた。
実装終わった後にテストを書くからつまんないの。
そう、それは。
それ言ったらちょっと間違えたかも。
順番間違えたかも。
テストを書く。
テストが足し算の答えが5になるってやつをやったら、
極端に言ったら、実装は
足し算ファンクション作ります。
足し算ファンクション、リターン5でいいです。
っていうテストを書く。
実装を書く。めっちゃ簡単に言った。
もう、本当はやらないけど。
極端に言ったらテストを通すだけだから、
足し算すら書かずに、リターン5でも。
固定値を書いちゃうくらいの。
なるほど。
の、次元で、
これは極端な例だけど、そのくらいでもいいみたいな。
ペックさんが言ってるんです。
最初はテストを通ればいい。
サイクルの説明をしたくて、これで。
なるほど。
簡単ここまでやらないけど、そのくらいの極端。
次のリファクタリングのところで、
A-Bをリターンする。
の、書くみたいな。
とりあえずテストを通るもの作って、
とにかく通すって。
で、通って気持ちいいみたいな。
プロトタイプ作って、
綺麗にするのは後からでいいよみたいな。
そう。
っていうのがTDDのいったんのサイクル。
そうなんですね。
先にテストを書く理由と自信
で、先にテスト書くのは面倒ですよね。
面倒っていうか、なんで書くのか意味わかんない。
今の。
で、なんでこれ先にテスト書くかっていうと、
先にどう動いてほしいかを、
実装の前にイメージしたいんですよ。
あー。
わかったかもしれない。
あれですよね。
テスト書くことで、
仕様が固まるってこと?
ちょっと先に言わないでください。
すみません。
テスト書いていくと、
どうやって作っていきたいかなみたいな。
どういう結果が欲しいんだろうっていうのを先に考えて、
それに対するアプローチを順番にやっていくじゃないですか。
先に実装を書いてしまった場合、
その実装を通らせるためのテストを書いちゃいそうじゃないですか。
いや、めっちゃわかりますね。
特に急いでるとね。
急いでやってると、このテストだから大体こんなことをやればいいかなみたいな。
そうすると、どうなりますか?
実装に合わせるから、
漏れちゃうパターンとか出てきちゃうんですよ。
それが聞きたい。
そう。
ですよね。
最初にちっちゃくテスト書いて、
で、ちっちゃく成功していくっていうのを
どんどんどんどん積み重ねていくんですよ。
そうすると、
自分が書いたところは全部担保できてる状態が
どんどんどんどん積み重なっていくのわかりますか。
失敗パターンが
全部割り出されてるから
どんどん正確になっていくみたいな。
どんどんどんどん自分の書いてるコードが
正しいという証明のコードが
どんどんどんどん増えていくみたいな。
そうです。
失敗を知らない
わざといろんなパターンを出すことで
失敗パターンを全部潰すから
結局最終的には成功。
一番いいパターンになってる。
で、ちょっとこれは
今回思ったことであって
ケント・ベックの迷いから得る自信
本を読んでる時は
この本の内容的に
ケント・ベックさんという人と
実際にコードを書きながら
ペアプロみたいな感じの本が進んでいるんですよ。
ケントさんと?
先ほどの足し算の例が本当に
一番の例で
本当にベックさんはリターン5で書いてたんですよ。
最初にこのぐらいでやりましょうみたいな。
すごい切ってますね。
そうやって書いていくと
教科書的にこれがいいみたいな
どんどん並んでるんじゃなくて
このケントさん、ベックさんも
著者が迷いながら
進む様子が書いてるんですよ。
これ実装ここまで書いたけど
やっぱ違うかも。
みたいな過程まで
全部本の中に書いてあるんですよ。
何が言いたいかというと
テスト駆動開発って本書いてるじゃないですか。
本書いてる人も
同じだなみたいな。
なんか自信になりますね。
こんなすごいめっちゃ売れてる本書いてる人なのに
最初から全部書いてるわけじゃないんだよ。
なんかすごい人のイメージって
最初からもう
上から下までバーって書いていく
イメージないですか。
天才プログラマーみたいな。
全部わかってたみたいな。
完全に理解したみたいな。
かなって思ってたら
実はこの人も
途中まで書いて
やっぱ違うかもみたいな。
そうなんだ。
実際に後書きのところも
途中まで書いたけど
一旦全部コード
一から書き直しましたみたいな。
本書く時に。
このレベルの人でも迷いながら
一個ずつ
調整しながら進んでいるっていうのがあって
これ嬉しいなって。
なんか親近感起こりますね。
嬉しいありがてーと思って。
っていうのがこれ結構
テスト駆動感覚もそうですけど
これを知れたっていうのが結構
嬉しいなと思って。
やっぱり
天才にも苦悩もあるんですね。
天才だと思ってたけど
実は本当に基礎的なことを詰め重ねて
小さく試して間違えて
確認して直しながら
少しずついい形に近づける
近づけることができる人が
すごい人なんだなっていう。
いい話。
トライアンドエラー
トライアンドエラー
そういうことです。
不安が退屈になるまでテストする
でもそういうの見るとやっぱり
自信になりますよね。
これが一個伝えたかったんですよ。
TDDを通して。
で
こう
TDDの良さっていったら
少しずつ積み上げていくから
理解ができやすくなる。
もうすべて理解した。
みたいな状態に
なんとなくなっていくの分かりますか?
理解的に
あれ思いました。
テスト一個一個が
チェックポイントみたいになるから
だから
そこで一回立ち止まるから
時間かけていろいろ積み重ねていくから
実装メインでやるよりも
焦らない。
ちゃんと一回一回立ち止まれるなって
思いましたね。
これテスト書くときに
どこまで書くんだ問題ないですか?
分かります。
まあ書いていくはいいけど
これどこまで
書こうと思ったらいくらでも書けるじゃないですか。
これどれくらいまで書くと思いますか?
これ言ってたんですよ。
当てていいですか?
当てないでください。
最小限?
最小限?
最小限じゃないですよ。
違う?
これこれ名言。
不安が退屈になるまで
テストを書くんです。
めっちゃいいこと言いますね。
これ名言じゃないですか。
だから
最初テスト書かないと
不安みたいな
保証できてる場所が分からないから
不安だなみたいなところあるじゃないですか。
不安だなって思うのが
退屈だなってところまで書くらしいです。
なんかこれ
テスト以外にも言えるな。
めっちゃいい言葉じゃないですか。
めっちゃいいなと思って。
これ仕事とかでも言えますね。
確かに。
業務とかでも
不安が退屈に変わるまで
やる。
なんか一種の基準ですね。
これ名言です。
なんかいいこと聞いた。
だから
もう面倒くさいなってところまで書いたら
そこがテストオッケーなんですね。
てことです。
これ結構抽象的だけど
分かりやすいんじゃないかなと思って。
具体的に言ったらだけど
例えば条件分岐とか
ループとか
いろいろな
壊れやすい箇所を直していくって思うんだけど
壊れやすい箇所って言われても
分かんないじゃない。
壊れやすいんだみたいな。
だから面倒くさいなと思うまでやる。
これが大事らしい。
で
TDDっていうのは
今言ってた通り
コードを書く技術っていうよりかは
開発者の不安を
コントロールするんです。
コントロールする技術です。
マインドセットってことですね。
これマインドセットってめちゃくちゃ楽になるんですよ。
TDDで書くことによって。
そうですね。
心理的に
軽くなるかもしれない。
だから
作っているコードが多分動いてるなって
思うんじゃなくて
少なくとも自分が書いたところは
テストで振る舞いを保証できてるっていう。
そういうマインドセット感覚になるんじゃないかなと思って。
いいな。
なるほど。
ですよね。
品質の担保を
今風な言葉で言うと
見える化したってことですね。
いいですね。
ナイスサマリー。
これが
テスト駆動開発の
まとめ?
テスト駆動開発とは?
こういう開発手法があるよみたいな。
メソッドですね。
これで
AI時代のTDDと小さな積み上げ
AIの時代の話に移るんですけど
AI時代
大人?
コード全部書いてくれるじゃないですか。
たまに
AIエージェントとかも
TDDで書いてくださいみたいな
指示とかも
できるじゃないですか。
できるんだ。
自分TDDを知らなかった。
仮に
AIエージェントとかに
TDDで書いてくださいみたいな。
確かに
AIもTDD理解してるんで
先にテスト書くんですよ。
これは
本的に言わせると本質ではないというか
ちゃんと
積み上げていくことに
意味があるって。
AIエージェントとかに対すると
本当にただテストを先に書いてくるんですよ。
テスト書いて
こっちに確認を取ってきて
進めて実装しますみたいな
手順になってて
確かに
テストを先に書かせるってことはできるんだけど
本当にやりたかった積み上げができないんですよ。
結局実装と一緒ですね。
一気にバッて終わっちゃう。
結局テストを先に書かれても
一気にバッて終わっちゃうから
本当は
そうじゃないけどなと思いながらやってます。
でもあれかもですね。
今聞いて思ったのが
AIに
こういうテスト書いて
って言った時に
もうすでにこういう処理っていうのは伝えないといけないじゃないですか。
テスト書くために。
どっち先にAIがやってるか
わかんないじゃないですか。
テスト
なんで
テストから考えてるんじゃなくてもしかしたら中で
これからこういう実装するから
こういうテストを
とりあえず投げとこうって考えてるのかな
とか思うので。
だから今回
これもTDDでやるんだとしたら
本当に
小さい単位を
AIアジェットと一緒にやっていくのがいいのかなと。
さっき言ったら足し算のところ。
本当にこの
なんだろう
でかい機能の中の一部からやっていくみたいな。
あー
ちょっとずつ分けて
ちっちゃいところをTDDで書いていく。
それを積み上げていくっていうのが
本当にやった方が
いいことかなと
思いましたね。
えーもう一回ですか。
今のところだけ。
いやなんか踏み落ちそうで
まだ自分が紙砕けてなくて。
あーそうか。じゃあ
ここまで
わかりましたよ。
AIに全部まとめてさせるのは
チェックポイントがないから
よくないっていうのはめっちゃわかったんですけど
その後のこと
いいこと言ってる
感じで
結構フワフワ喋ってるから。
あー
舞台で言うから
例えば何の機能があるか
例えば
小さく実装させていく
みたいな話なのかな
それのメリットが
今見えてないかもしれない。
メリットはさっき言ったときに
自分が把握できている
場所が増えていく。
あーなるほど。
積み重ねることができるっていう。
まとめてやっちゃうと
自分自身もどんなテスト書いたか
わからないけど
小さい単位でやっていくと
一個一個理解して
進んでいくみたいな。
わかりました。ありがとうございます。
100行200行一気に書かれても困るじゃないですか。
うんうん。
本当に数行単位で
少しずつ積み上げていくのが
いいよねっていう。
それやっていくと
本当のEDDの良さが
表示できるのかなって。
自分もそれは同意ですね。
へー。
素敵な本ですね。
そうなのよ。だからこそ
AI時代はEDD重要ですよって話ですよ。
あー。
先にテストを書くことで
AIに何をやらせたいかを
自分の中で明確化できる
テストを先に書くんで。
人間が正しさを定義する
で、AIが出した実装は
正しいかどうかも
最初自分がテスト書いてるんで
確認もできます。
はい。
で、リファクタリングをする時も
テストが通るかどうかで安全性の確認で
やったりとか
そういうこともできたりします。
これ今自分が思ったのが
これ
AIが実装する時に
リターン後みたいに
返す可能性あるなってちょっと思った。
あー確かに。
そこはどうするの?
ちょうどそういう記事を読んで
テストを通すために
ハードコーディングして
絶対返すように書いたみたいな
やっぱ
人の目はいるよなって思いました。
そうです。
このテストコード開発もやっぱり
自分の理解を進めること
自分の理解を高めることがすごい大事なことだから
AIをやっていく中で
もちろんコードを読むことが大事
っていうのを
AIはそれを助けてくれる感じで
使っていくのが
いいですね。
あ、ですね。
すみません。余談になっちゃった。
いや、ありがとうございます。
話聞いちゃった。
結論としては何を正しいとするのかを決めるのは
人間側の役割。
一致してた。
それをテストとして定義した上で
AIを活用する姿勢が大事。
ですね。
ということで
ここまでいって
EDDテストコード開発は
先にテストを書くことだけじゃない
ということが
あったんじゃないでしょうか。
めちゃくちゃ分かりました。
すごく明日からでも
使えそうな
内容だったな。
テストから設計を見直す
TDDっていうのは
設計処方であるっていう
本の中で結構言ってるんですけど
私の例えばですけど
はい。
テストが長すぎたり
テストの前に
いろんな準備をしないといけないみたいな
たくさん作ってるとか
ぐちゃぐちゃしてると
テストが長くなっちゃうなみたいな。
はい。
テストが長いってことは
関数めっちゃ長いんじゃないかみたいな。
そういうことも分かる。
テストがあることによって
テストが長すぎたり
なんかこう変な
処理してんじゃないかとか
テクストの
書きにくいテストが出来上がってる時点で
その実装が変なんじゃないかみたいな。
あー。
責任が集中してないかってことですよね。
逆に言ったら簡単にテストを
簡単なテストがたくさんバッって書けたら
実装もシンプルで
分かりやすくなってるはずだろうみたいな。
かもしれない。
そう。
っていうのが設計処方があるっていうことで
言ってたんですけど
それ結構大事というか
良くないですか。
めっちゃ良いと思いました。
テストは先に書くだけじゃないんですか。
そう。テストは先に書いて
それを積み上げていくことでそういうことも分かってきたり。
考え方みたいなカテゴリーでもあるんですか。
TDDのまとめと実践
まとめに入ります。
で、TDDっていうのは
不安をコントロールする技術である。
はい。
小さな確認をしながら進むことで
多分動いてるから
ここは保証できてるっていう感覚に変える。
で、TDDは
進め方そのもののこと
テストを先に書くだけじゃなくて
小さく試して
小さく直す。
サイクルを回し続けることが
テスト行動開発になります。
テストを先に書くだけじゃないですよっていう。
そういう開発サイクルの
やり方なんですよ。
その開発サイクルの中には
こういう思想が
積み込まれてるんだなって。
次の仕事から意識できそうですか。
ちょっとこれ使いますか。
ちなみにこのメソッドは。
自分使う。
さっき一番使おうと思ったのは
テストが長いってことは
関数がいけてないんじゃないかって。
話が
すごい分に落ちて。
その確認方法いいなって。
テスト行動開発よりも
不安がなくなるまで
退屈になるまでって
めっちゃいいなって。
今日これ聞けただけでも
これ聞いた価値ありますよ。
いや本当です。
なんかいい話
聞けてよかったです。
結構ちゃんと
理解してくれたようで。
こちらこそ分かりやすいですね。
嬉しかったですよ。
今度本課せんで。
ぜひぜひ読んでください。
ということで
今回のテスト行動開発の話は
終わりたいと思います。
ありがとうございます。
また次回よろしくお願いします。
よろしくお願いします。
またねー。
バイバイ。