この番組はエンジニアの成長は楽しい学びからをもっとにエンジニアリングに関する学びをワイワイお届けするラジオですワイワイワイワイワイはいワイワイしていければと思うんですけど本日ですが過去の僕に向けて喋りたいBDDの話ということであ出たBehaviourDriven Developmentどぅ

はいなんですけど先日ですねお便りでBDDちょっと触れたところがありまして適当こきすぎてたなというふうなところをちょっと思いましてなるほどはいさすがにちゃんと勉強してちゃんと話そうそうしないと収まりがつかないという僕の中の衝動でざっと本を読んでバッと話すという回になりますすごいアウトプット駆動型成長エンジニアだ

まあそうかもそうかもしれないODDですかODD最後のD何じゃデベロッパーデベロッパーよかったねあって危なかったです本日ですがThe BDD Books Discoveryっていう書籍ですね書籍はい書籍

これはBDDに関する本ってあんまないんですけどそれに書かれたそのBDDを書いた珍しい本でなんとあのブロッコリーさん役ということですげえブロッコリーさん役の本なんですけどはい

別にブロッコリーさんだから選んだわけではなくてですねてかもともと知ってたんですけど会社の人が読んでたの見てたんでやっぱりBDD本って調べるとね一応最初に出てくるんですねこれが学んで読んでみましたし面白いこの本3部構成というか3冊構成になってて冊?冊冊?え?超中下ってこと?ディスカバリーフォーミュレーションオートメーションだった気がするちょっと待って違かったら

ちょっと後で調べて概要欄載せとくんですけど3冊構成の7少なくともあってるで2冊目がフォーミュレーションなどもあってるちょっと3冊目わかんないですすごいなでもボリュームやばそうじゃないなんか今のところハリーポッターのアズカ版の囚人までぐらいを想像してるんですけどディスカバリー100ページぐらいですねそんなないそんなないというか全体的にそんなにですねボリューム感は読みやすい感じでなるほどはいじゃあちょっと早速いくんですが

BDD 僕はですね BDDのことをかつてはTDDのちょっと抽象度高い版だと思ってましたインテグレーションテスト UIの振る舞いに焦点を当てたテストコードを書きつつそのテストコードに即した動きを作って

なおかつなんか出てくるドキュメントは自然言語的に書かれてるからまあみんな見やすいよねみたいなそんなイメージだったんですけど断じて違うとは言わないが違うっていう断じて違うとは言わないが違うラーメンとうどんぐらいの違いってことですかいいとこ行きますねラーメンとメンマぐらいですね多分

全然違うじゃんいやいやいやでもちょっと入ってるじゃないですかラーメンやっぱりちょっと入ってるあーそういうことかトッピングされてるよっていうそういう感じねまあそうねトッピングなんですよ僕が今言ったのは要はなんか全体の何か流れがあってその中の一個を切り取って強く出してしまったみたいな

ラーメン注文したのにメンマだけ来てしまったみたいなそういうことですかラーメンのことを説明するときにメンマのことをひたすら喋ってたっていう僕でしたねどうだったあそこのラーメンっていやー茶色くてさここまであってそうですね茶色いのね茶色あってそうだなはいちょっとそろそろ本編いくんですけどはいBDD何が目的なんかっていうのはこれはですねえー

ビジネス担当者スクラムで言うとPOなのかなPDMかもしれないですけどあとは普通にウォーターホールで言うと企画とか呼ばれる人この人がより良い形でより良い形で参加する参加できるこれが一番ふわっとしたBDの目的ですより良い形で参加できるはいより良い形具体的に言うと何か

というとちょっとこれは歴史を遡っていくんですけどこのBDDっていうのはダン・ノースさんっていう方が提唱し始めた概念でこのダン・ノースさんは僕が今読んでたThe BDD Books Discoveryの著者だと思ったら違かったわすいませんなんでもないです著者みたいな雰囲気出してる違う人はい

失礼しましたっていうのがダンさんが言い始めたんですけどテストツール例えばJUnitとかPython.pyTestPHPだと何でしょうねっていうPHPユニットとかあると思うんですけどJUnitとPyTestについてはテストを回す際にはメソッド名にテストって付ける必要があるんですねこのテストについて

ワードをつけなければいけないという制約上テストコードを書いていくにつれて設計とかドキュメントを期待する振る舞いみたいな本来の目的っていうんですかねコードはあくまでビジネス的な課題を解決するためのものなんでそのビジネス的な課題とあとは具体の実装のテストコードこういう両者のギャップが広がってるよねっていうのが断算的に課題感を持ちましたとほう

元々大事なのってビジネス的なビジネスの課題をどう解決するかどうっていうのは抽象度が割と高いところ例えばですねお金を1万円引き出せるようにしたいっていうビジネス的な課題があった時にATMを思い浮かべてカードを入れて暗証番号を打ってお金入力して出勤ってやるとお金が出るみたいな流れが多分振る舞い

になるんですけどユニットテストとかの単位だと口座残高から1万円引くみたいなカリキュレートロジックがあったとしてそこの単位でテストするじゃないですかなるほど不足したらエラー出すとか足りてたら下ろすとかそういうことですねそれはもちろん大事なんですけどビジネス要件にもあると思うんですけどややユーザーストーリーというか

からはギャップがあるじゃないですか今の具体例がひょくなさすぎてちょっと距離感感じれないと思うんですけどただちょっと距離があるユニットテストレベルのメソッドとかありそうだなと思うじゃないですかその辺がやっぱり離れすぎているのは良くないよねっていうので要件とテストの関係を維持するためにビジネス担当者にこういう振る舞いをしてるけどいいよねっていう

コミュニケーションを取るツールとしてBDD振る舞いで

こういう風に動きますっていうコミュニケーションを開発者と企画の人との間でコミュニケーションを取ることによってフィードバックサイクルを早くしようそれはソフトウェアとテストコードのフィードバックサイクルじゃなくて企画とデベロッパーあとはテスターその3社間でのフィードバックサイクルを早くしていこうねっていうのがBDDという概念なのでこのダンさん

このBDDというワードからテストという言葉はあえて消してるんですねそういえばないやんって思うんですけどだからこれはテスト従来のテストとかテストスキルに変わるもんじゃなくて本当にフィードバックサイクルを速くするためのものなんですよもっと言うとテストしてなくてもBDDなんですよテストしてなくても言い過ぎだわテストを自動化してなくてもBDDなんですよ主導で試しててもってこと?

手動で試しててもそうですね大事なのはあくまで企画とデブテスターの間でコミュニケーションを取ること本番環境じゃないけど触れる環境を早めに作ってそれを触ってもらってそこでフィードバックもらってみたいなのも講義でいうBDDに当てはまるみたいなそういうことですかちょっと微妙だと思っててそこが微妙だと思うかもしれないみたいなニュアンスを伝える具体例の話をしますねはい

BDDどうやって進めていくかBDDっていうのは3つのフェーズで進んでいくんですねそれがフェーズ1ディスカバリー発見フェーズ2フォーミュレーション定式化フェーズ3オートメーション自動化なんで最初に共通理解このユーザーストーリーに対する共通理解を発見して

なんかこれとこれとこれ例えばだからさっきのATMのお金引き出すだと確かに残高不足の時にはエラー出さなきゃいけないやとかはユーザーストーリーには含まれてないけど確かにそれはあるじゃないですか途中でキャンセルしたら戻れるとかそういうのを発見して発見したものを定式化してシナリオの形で

いざ定式化したやつを最終的に自動テストに落とし込んでいくこれがPDDの進め方になっていますなのでスクラムイメージしていただきながらざっくりやり方を話していくとちょっとさっきも言ったかもしれないですがスクラムのスプリントプランニングとかバックログリファインメントみたいなユーザーストーリー

チケット渡されてこれどうやって実装していこうかなみたいな計画をする段階でさっきで言う発見の作業をします発見は3アミーゴスと呼ばれる3人の愉快な仲間たちでしたっけUML提唱した人たちですよねとは別で同じワードで多分違う意味なんですけどこの書籍ではビジネス担当者開発者テスターの3つのロール

多様な視点を持ってユーザーストーリーの分析を進めていきましょうと言ってますなるほどねバズとウッディとアンディみたいなそういうこと?そうそうそうそうアンディだけ立場違いすぎますけどねバズとウッディはおもちゃだけどアンディだけオーナーなんでそうなボーピープとかにしておいた方がよかったもう一人知らないですけどなのでユーザーストーリーの付箋をバーンって貼ってじゃあこれってこれも検討必要だねみたいなブレストをしていきますうんうん

でブレストをしていってこのケース考慮必要だねこのケース考慮必要だねっていうのを企画とか開発者テスターの3人の視点を持ちながら出していってじゃあはいいざ実装を進めましょうねっていうフェーズになってから定式化とテストの自動化BDDでいうとテストの自動化するんだったら最初に多分自動化のテスト書いて

これはTDDと一緒でレッドグリーンリファクタリング的に落ちるテストが開いて具体の実装入って具体的な実装の中でTDDを回してよしある程度できたわBDDのテスト回そうでテスト回して位置機能できるというか位置振る舞いできるっていうんですかね位置シナリオできるかっていうのがBDDの開発サイクルになっていきますなるほど

なんでですねあと補足的なというかさっきシナリオっていう言い方してましたけどこういうの考慮必要だよねっていうのでATMの話で言うとユーザーは途中で取引やめたくなったら×を押して戻れることみたいなこれがいわゆるBDDってワードが出てきた時に出てくるようなガーキン規法これシナリオテストでよく使われるんですけど

例えばATMでお金を下ろすっていうフィーチャーがあった時に残金が十分な場合お金を1万円下ろせるというシナリオがありますとそのシナリオに対してギブンこの時単体テストでいうトリプルAみたいなに似てるんですけどお金が十分ある時1万円下ろしたら全1万円が出てくるみたいな

そんな形で前提条件とやることと結果を記載する記法書く方法記述方法がガーキン記法と言います

これがですね非常によくできてるというか単体テストも近いからっていうのもあるんですけどこの時こうやったらこうなるよねっていうのを明記できるわけじゃないですかBDDでは自然言語でどういう時にこうやったらこうなるっていうのを書いていくので細かいユーザーストーリーに関わる動作について企画の人に合ってるよねって早めに言えるんですよなので

BDDのフェーズの発見の定式化発見の後の定式化やった後にガーキン記法でこの時こうやったらこうなるっていうのをバーって書いていってこれで作ろうとしたものが合ってますよねっていうのをやることで作った後に違うって言われて手直ししなきゃっていうのを早めに気づけてフィードバックサイクルを早くできるっていうのがBDDの旨味というかというもの

最初にしっかり擦り合わせができるってことかそう最初にしっかり擦り合わせする開発ですねこの本1冊目ディスカバリーっていうのでまだ3分の1なんですまだまだ書いてることがいっぱいあるかもしれないんですけどこの本読んでて学びはいっぱいあるつつもマジかって思ったのが一つあってちょっとそれを紹介するんですけどビジネスチームが参加していないBDDほう

これはですねBDDではないではないではないってとこまで言ってなかったかもしれないですけど握手やるなこれあのそうBDDをやってるっていう現場はちょいちょいあると思うんですよ一方でビジネスチームは参加してないみたいなのも結構ある気がしてて結構あると思うんですよいやまぁちょっと主観なんですけどでもなんかBDDやってるって

言ってる開発チームそれはBDDじゃねえよみたいななるほどねような書き方をしていて僕はそう受け取ったんですけどもしそうなのであればビジネスチームが参加できるようにするためにまず一旦デブチームはBDDやってもそんなに稼働増えないよみたいなそういうトライアル的な意味合いで

やってるんだったらいいけど別に参加するわけでもないBDDに関してはもっといいやり方あるかもねみたいなっていうのを書いててBDDへの考え方というかテストに焦点を当ててるわけではなくてあくまでビジネスチームとデベロッパーのコミュニケーションとかフィードバックサイクルを早くするこれに焦点を当ててるんだというのを書いてる部分というかここの部分から受け取ったので

僕としては今まで勘違いしてた分が腑に落ちたというかこういう哲学だったんだなというのが勉強になりましたなるほどっていう感じですねちょっと解釈が合ってるかどうか確認してもらっていいですかはいまずBDDは開発者と企画者とテスター

が早めに認識をすり合わせて開発を進めていけるといいよね開発手法でその最初の認識合わせのすり合わせとしてE2Eテストなりシナリオテストなりを使って認識を合わせてるみたいな感じのイメージですかE2Eとかシナリオテストではなくてもっと前段階のシナリオで

シナリオって言ってるのはシナリオテストではなくて本当にガーキン記法とかガーキン記法じゃなくてもいいんですけどこういう時に何やったらこうなるみたいなものを自然言語で書いたメモか何かそれですり合わせをしていますすり合わせした後に自動化のテストを書きますなるほどちょっと今の開発現場がもしかしたらそれっぽいことをやってるかもって思ったんですけど今ってバックログでチケットが振られるんですね

でそのチケットに対して最初にこういうことを満たせてたらいいよねみたいなテストじゃないけどチェックリストみたいなやつをチケットに書き込むんですよそれを企画してる人に見てもらって認識合ってるかどうかをチェックするみたいなことをやってるんですけどそれはなんか近しいイメージですかそうですねでそれに加えてちゃんとインテグレーションテストかけてればっていうところな気がしますねインテグレーションテストはかけていませんふふ

その何でしょうBDDのメリットの中で企画とのコミュニケーションが活発になるというかフィードバックサイクル早くできるというのもあるんですけど自然言語で書かれたテストコードがあるので生きたドキュメントが作れるんですよそれで

その生きたドキュメントを作るのもBDDの目的というかの一つではあるのでやってることはでもなんだろう哲学というか仕事の進め方としてはいいと思うんですけどBDDやってますって言うには若干足らない気もしますねなるほどね承知です今日すっごいざっくり喋ってるんで音声に乗せるので

ぜひ読んでみると面白いと思いますこれはすごいサクッと読めました僕は1週間かな1週間ぐらいで1週間の隙間で読んだんで4時間かな3時間とか3、4時間ぐらいかなそんなかかんないかなもう一回証明いただいていいですかザ・BDDブックスディスカバリーという本ですザ・BDDブックスディスカバリーディスカバリーだけで4時間

2,3時間3時間くらいThe BDD Books3冊なんでBooksなんですねちなみに僕最初間違えてフォーミュレーション買って2冊目やんけってなってディスカバリー買いました買い直しましたよく読めばいいだけなんですけど数字が書いてあった方がどれが1冊目か分かりやすいですね確かに確かにはい

これ今何分くらいお便り読もうかな24分ちょっとじゃあお便り読みますラジオネームゆうさんからのゆうさんこれ同じ人かな同じだと思う同じ人かもしれないちょっと僕が前回BDD適当超えてすいませんでしたでお便りで

感想の方から聞きますねのりさんかいちさんじゅんぺいさんこんにちはかいちさんスモールテストの開発説ありがとうございましたとてもわかりやすかったですお便りの中でスモールテストとあえて使った理由についてですが単体テストという言葉にはデトロイト派とロンドン派という2つの異なるアプローチがありデトロイト派はMockやStubを使うことがありますが依存関係に過剰に依存せず

できるだけ実際の動作に近い形でテストを行うことが特徴ですそのためテストサイズでいうと時にミディアムに近いものに含まれるのかなと思いましたそのためロンドン派の単体テストをさせているということを伝えたかった次第ですなるほどねデトロイト派とロンドン派という言葉が出てきたのでお三方に質問です単体テストを書くときデトロイト派とロンドン派はどちらを意識していますかこれなんか一回話した気がするなあれですね単体テストの考え方の本を会長が紹介したときのやつかな

そうかもしれないそうですね多分記憶がデトロイトなんだっけなどっちが古典学科だっけなロンドンですねありがとうございますデトロイト派は他のメソッドとつなげて動かしますけど古典学科は本当にメソッド単位でテストするようなイメージですね僕はデトロイト派で書いてますしそうじゃない現場はあんまり見たことないけどどうですって

言うて僕はあれですね無宗教というか書いてない派なんですけど書くとしたらデトロイト派ですねデトロイト派になってるんじゃないのかなしばらく書いてない気はするんですけどフロントの方のテストが多いのででもそれでもあれなのかなメソッド単位がロンドンでしたっけそう

そのメソッド単位って言ってるのは他のメソッドを呼び出してる時はその他のメソッドはモックにするはいいやまあデトロイトですよねまあどっちもいいと思いますけど書籍とかあと何でしょうねTワダさんの話とかだっけなやべTワダさんどっちだっけな割といろんなところで伝え聞くのはデトロイト派の方が好みっていう人が多いイメージだな

単体テストの考え方の本でもどっちもあるよと言いつつもデトロイトを押してる感は出てたよねありましたね押してましたねモックいっぱい作るの大変なのと実際の動き実際は落ちるけどモックなら動くみたいなことが発生し得ると思うんでデトロイト派の書き方でやると

1個ダメだった時に複数のテスト落ちてどこが悪いか分かんないじゃんみたいなことはデメリットとしてあるかもしれないですけど単体テストでやりたいなんかどっか壊れてないかなが少なくともダメだっていうのが分かるんでっていうのがデトロイト派の意見ですはいはいってのでちょっとこっちじゃなくてポッドキャストで話してほしいことはい

現在ウェブアプリをフルスタックで開発していますTDDで開発を進めていますがまだ経験が浅く単体テストしか書いたことがありませんそのため統合テストやE2Eテストをいつ書くべきかどういうタイミングで書きたいと思うかが分かりません本当は単体テスト統合テストE2Eテストをそれぞれ意図を持って書きテストを通じて実装に対する自信を積み重ねていきたいと思っていますそこでのりさんかいちさんじゅんぺいさんに質問です統合テストやE2Eテストはどんなタイミングで書きたいと思いますかE2Eテストテスト駆動で

やろうって厳しくはないかうーんとテスト駆動でやるテスト駆動でやるあんまりないんじゃないどうなんでしょうねあんまり想像できないですね難しいなって思いましたうーんなんか

テスト書いてない側からの勝手なイメージなんですけど単体テスト書き上げて機能を作っていくじゃないですかその結果最終的な振る舞いじゃないとテストできない部分だけをE2Eとかでやっていくのかなっていう気がするので割と後半で書くんじゃないかなって気がしますてかあれってぶっ壊れやすいテストだからあんま最初にやんないんじゃないかなって気がしますねそう思いますE2Eはそうだとして統合テスト

統合テストか統合テストインテグレーションテストかインテグレーションテストはでも実装して最初のプロリークというか出す前にやるんじゃないですかねユニットテスト書いて書きながら細かいことやっていって実際に作ったやつちゃんと動くかなインテグレーションテスト統合テスト結合テストでやっていくかなと思ってますE2Eテストに関しては

開発のスタイルによると思っててアジャイル的に本当にバンバンリリースしていくんだったら多分一機能を書くことに機能によってはやる気がしますしウォーターホールとか納期がある系だったら多分他のシステムとかが出揃った後にやるんじゃないかなと思いますなんでまず言いついというよりは統合テスト結合テストインテグレーションテストをやっていくのが

やるというか一期の実装するごとにやっていくのかなっていうイメージですねというのでちょっと子供がブチギレてるんで優さんには申し訳ないですけどそろそろ締めようかなと思いますはいお便りありがとうございました参考になれましたら嬉しいです僕もちょっとテスト詳しくなりたいのでまた疑問あったら送ってください相変わらず質問のレベルが高度なので戸惑いつつ話してますが

めっちゃいいと思いますので頑張ってくださいではハッシュタグひまじんプログラマーでSNSNEXTでフィードバック募集してますので今日のお話に関するフィードバック感想ありましたらお願いしますお願いしますあとは各種ポッ違うわGoogleフォームで番組のお便り予防感想質問などもお待ちしてますお願いしますますあとは各種ポッドキャストプラットフォームのフォロー高評価もお待ちしてますお願いしますます

ではまた次回バイバイ