カイチでございますカイチでございました本日はですね定期的に言ってるんですがユニットテストについてお話をしますUTってやつですね単体テストってやつですね今日は駆け出しエンジニアの人がユニットテストを書くときに

そのユニットテストのライブラリとかの習得を早くするべくユニットテストって大体こんな感じの構造になっててだからこういう機能があってこういう風に使えばいいんだねみたいな話をしていきますなるほどでもう一個もう一個欲張り僕が本当に伝えたいのはユニットテストの花高話を一つだけ盛り込んでなにそれえ?

最後自慢して終わるっていう認識でいていいですかそうですねこの話を聞くとちょっとどやれるっていうはいかいちがいやいやいや聞いた人がねなるほどねびっくりしたっていうのをちょっとやっていきたいなと思いますお願いしますなのでユニットです結構めんどくさいなっていうイメージを持ってる人が多いかもしれませんがまあまあ楽しく感じれるようにユニットのテストってこんな側面あるんだっていう新たな側面に気づければなと思いますうーん

というのでまず最初です最初のりさんに質問なんですけどユニットテストにおけるのりさんの学派を聞きたいですね学派ですかあれですねはい

ちょうど新州 宗教やんすよなんですか学派って わかったかもしれない 前言ってたかもしれないそれポッドキャストですか? 言ってないですよ 文記網羅か命令網羅かじゃないですか?違いますね はい

違いますカバレッジの話ですねカバレッジの話じゃなくてカバレッジによるC0学派とC1学派とっていうやつがあるんじゃないですか違いました残念ながら違いましたってなるとまだいけないですねあれか

モック使う学派と使わない学派おー正解を引いていく本当に?はいういー正解を引いていくういーあのですね単体テストというかユニットテストの会話にはですね2つの学派が存在しますロンドン学派とデトロイト学派うわーまじかはい

都市都市でロンドン学派の方がテスト対象の依存関係全てMockに置き換えるっていうスタイルですねなるほどなるほどデトロイト学派の方は基本的にMockに置き換えず外部のものだけどうしてもしょうがないだけはMockにしてうん

やっていくみたいなのがありますとなるほどロンドン学科の方は単体テストごとに単体テストじゃないですすいません単体のメソッドとかクラスごとに検証していくのでエラーがあるコードがある場合にしっかりとそのメソッドのテストがこけるうんうんうん

だからこっちのテストのやり方の方が良くねって言ってるのがロンドン学派ですねデトロイト学派の方はMockを使わないので何かのメソッドがおかしい場合にいろんな単体テストがこけちゃいますだけどロンドン学派はMockが間違ってる場合に全部通して動かすときに本当は動かないのに単体テストが通っちゃうっていうのが起こりうるんですよなるほど

そんなおかしくねえかっていうのがデトロイト学派ですなるほどね実際に動いてるものが正義じゃないそうですねって言ってるとはいでちなみに僕はデトロイト学派派です学派ですうん

ロンドンに1回行って結合した時大変じゃんしかもモック作るの超大変じゃんデトロイト学派の方が効率良くねえかって言ってデトロイト学派になった人ですどちらかというとなるほどね僕はですね部分的ロンドン学派基本デトロイト学派って感じですね正直

そういう人が多いですヤンヤン デトロイド派もあれか必要なところはモックしてるからデトロイド学科に入るのか深井 そうですデータベースとかはモックにします他のテスト対象以外のクラスとかと共有してる依存関係のものだからデータベースとかですよね本当にはモックにしますデトロイド学科も多分そうじゃないとテストできないんでヤンヤン 確かに深井 はい

っていう感じであるんですけどぶっちゃけ多分どっちかに寄ってない人が多いんじゃないと思います時と場合によっては基本モックしないけどモックしなきゃした方がいい時にはモックするみたいな人が多いんじゃんとは正直思いますねっていうのはまず学派があるっていうのでまずここ花鷹ポイントです明日職場に行って周りの人に聞いてみてくださいどこ学派で所属されてるんですかって

ユニットテストやってますけどその人はオフィスから椅子全部捨てられないのか全部って何個もあるの1個じゃなくてね1個じゃないか1個だなちょっとわかんないですそれは自分と違う画家の人を見つけたら隠室ないじめをすると花瓶置いちゃう花瓶置いちゃう

学校のね 演出のいじめの代表例みたいなねなかなかないですけどねないよね 見たことないわまず学科が2つありますって話がはい

余談で入りました1個2つありますここから本編に入りますそうですよねその学派あること別に何も大事じゃないですよねでもテスト考える上でMockがあるメリットデメリットを今感じることができましたねなるほどねMockがあるとしっかり単体はテストできるけどMockが間違ってた時に

意味なくなってしまうとそうそうそうそう本編に行くんですが前回の前回じゃないです以前のエピソードでも何回か単体テストの話をしてたんですけどもその時に話していたEユニットテストってなんだっけっていうのをまず復習するところから入りますEユニットテストのポイント5つありました1つ目が破損を正確に検出する破損を正確に検出するはいコードが壊れてない時にはテストが失敗しないとうん

コードが壊れている時だけに失敗を検出するというのがまず一つ目ですね例えばですよ単体テストの時にテストデータを使うじゃないですかテストデータの構造が合っているのに単体テストが通らないみたいないうことってあり得ると思っていて

そういう本当は機能的に影響のない変更をテストデータに対してやった時にテストがこけるみたいなのは良くないちょっと待ってテストデータは合ってる作ったプログラムも合ってるけどテストこけるってことですか合ってるものがあった時にテストデータのプログラムの動作に関係ないところを変えてデータの形式も正しいはずなのに

データの全然関係ないとこ変えるだけでテストがこけちゃうのは良くないですっていうのが一つ目二つ目実装の詳細にとらわれないというのでホワイトボックスじゃなくてブラックボックスせよってことブラックボックスはいそうですリスポンスに関係ないそんなことありえないですけどリスポンスに関係ないメソッド内の変数の名前を変えただけでテストこけるのはダメだとほう

これ二つ目です今のは具体例でした一つですそれ以外にもあります三つ目よく説明された失敗っていうのでコードが壊れてる時にテストコードを失敗した結果がバーン出るじゃないですかその時に何がダメなんだろうっていうのが分かりやすいようなコードを書きましょうっていうのでテストメソッドの名前なのかライブラリで出るテストの

テスト名シナリオ名分かるようにしましょう4つ目が分かりやすいテストコード普通に分かりやすいコードを書いてください5つ目簡単かつ迅速に実行する時間がかからない重たいようなテストコードを書くなとあるわあったトークンの期限みたいなのちゃんと動いてるかテストするためにほう

トークンの期限を1分に縮めて1分スリープするテストありましたねなぜ1分なんだそれが最小値だったから最小値なんだララベルの仕様上の問題ですけど本当はどうするのがいいんだろうな5秒とかにできないんですかね頑張ってできなかったデータベースの仕様

ララベルの何の仕様? 樋口:ライブラリの仕様だからでもそもそもライブラリの話だからテストしなくていいんじゃねえかっていう説に今僕はたどり着いてます深井:まあそれはそうですね 樋口:はい深井:もしくはそのライブラリをモックにするんでしょうね 樋口:うん深井:5秒でもいいやつ返してくれるようにするのかなもしくは失敗するだから失敗するレスポンスを即座に返してくれるようにそのララベルのライブラリに何かかリクエストを送って

なんか失敗するレスポンスが返ってくるんですもんねエラーみたいな失敗ってかあれですね多分トークンのリフレッシュかなあーそういうことかなんかMockうまく使うんだろうなまあちょっとはいっていうので多分そういうのは良くないですよっていう全部で5つでしたはいでこれが単体テストでいい単体テストを書くので大事なことなのでこれを頑張って作れる作るというか実現できるように単体テストのライブラリっていうのはできてますとはい

続いて単体テストの構造なんですけど構造ですご存知かもしれませんが単体テストって一つのメソッドを思い浮かべてください思い浮かべましたシナリオ単体テストっていうのは基本的に3層構造になってます

1つ目がアレンジテストデータ用意したりとかテック用意したりするとこが1つ目2つ目がアクトテスト対象を実際に呼び出すところ3つ目がアサート実行した結果が合ってるよねって確認するチェックすると準備実行確認の3層になってます

この前普段Python触ってるんですが急にJavaScriptのテストしなきゃいけなくなってJavaScriptのテストフレームワークのJESTっていうのを勉強しながら頑張って単体テストとか作ってたんですけどこの辺を理解してたからJESTも公式ドキュメント見るだけでサクッとまあまあ使えましたとなるほど準備して試して

検証すると そうですこの準備して試して検証するっておそらく大体どの言語でも同じような機能が入ってます間違いないそれをちょっと次々見ていきますまず最初アレンジ準備するところですねここでは物の準備をするんですけどその準備にも何個か種類があって何個って言ってもそんなに多くないですと2個ですか?何個でしょうね2つ?3つ?3つ?はい

まず一つ目が基本的なセットアップなのでこれはちょっとライブラリ関係ないんですけども変数にだからアクトの時に使用するメソッドに対する引数を用意したりとかあとはクラスのインスタンスみたいなのがもし必要だったら用意するかもしれませんねログインしたりしますよねそうですねものによってはもしかしてこの後のやつですかログインを言ってませんでしたこの後が

モックとかスパイですねさっきも言ってたデトロイト学派でいうデータベースとかあとはロンドン学派でいうと別のメソッドですかねのモックその通りそれっぽく動く偽物の

ヤーツヤーツ偽物のヤーツを用意する機能が大体のテストライブラリには入ってますなのでアレンジの機能を探そうと思ったらMockとかSpyどうやって作るんだろうっていうのを勉強してみるとテストライブラリを使えるようになりますと確かにMockSpyとかであとあの

変数とかクラス用意するって言ったじゃないですかはいでテストライブラリにはさらにもう一個ですねこの準備を効率的にきれいに書くためにセットアップみたいな機能がありますありますねでセットアップっていうのはメソッドの中で準備するんじゃなくてそれを外出ししてうん

各テストメソッドテストケースを実行する前に1回ずつやるとか全部やる前に1回やるとか終わった後にそれぞれやるティアダウンってやつとかそういうなんか各テストケースを実行する前もしくは後に何かをやるっていう

機能がついてますイメージコンストラクターとかデストラクターみたいな感じだよねちょっと違うのインスタンス化のタイミングじゃなくて各メソッドの実行の前後でやってるってところですかねそうです普通に変数とかクラス用意するとモックとあとはセットアップティアダウンこの辺把握しときゃアレンジのところはOKなんでこれさえあればいいのでえっと

新しいテストフレームワークとか触るときとかユニットテストのライブラリを使うときはまず勘どころとしてこういうところをどうやって作るんだろうっていうのをまず最初に把握すると2つ目アクトですこれは実際のテスト対象のメソッドを呼び出すところなんですが何もないんですここは呼ぶだけですここ簡単だよね一番

ほぼほぼ1行です木を照らったことは何もないですよねアレンジは結構膨らみがちなんですけどアクトは多分1行でしかないです終わって最後アサートですねアサートはアクトで試したレスポンスをその通りになってるかなとか調べるとこなんですが見る観点としては何個かあると思うんですよこれね

僕ちょっとむずいっすちょっとむずいですかこれも結構いろいろ機能があってですね一番基本的なものはこの文字例えばアクトで返ってきたやつがこうなってるかって調べるのがまず1個で他には例えばデータベースをMockにしていてデータベース

ORマップはどっちでもいいですけどそのデータベースが何回呼ばれたかをテストすることもありますしデータベース呼ぶときに渡した引数どうなってるかとかその辺をテストするのが多いんじゃないかなと個人的には思っております依存ライブラリとどういうやり取りをしてるかと帰ってきたやつが何かかな他にもいろいろ見れるっちゃ見れるんですけども

ちなみにこの辺なんかありますか?いやーここら辺で僕が悩んでるのはじゃあどこまでチェックすればいいんだろうみたいなはいはいはいのさじ加減がむずいっすはいはいはいなんか基本的にこれはもうこれは完全に僕の意見なんですけどはい

関数の振る舞いを見れればいいかなと思ってますで振る舞いって言ってるのは関数を外から眺めたときにそこから出てるやつとかを見ればいいなのでレスポンスと依存するやつMockとして用意したやつとのやりとりのこの2点を見ればいいと思ってますなるほどね

モックとしてるやつに対してやり取りを見るのは多分入力引数と呼び出し回数が合ってれば合ってるだろうそれ以上多分ないはずそこから正しいのが返ってきてるかどうかはその関数テスト対象の関数が正しいものを返してるかで見れるはずなのでそのモックとのやり取りと関数のレスポンスを見れればいいかなと思っておりますなるほどねはい

ただ全然諸説ありますし本によって全然多分言ってること違うことはありますそうなんですよねどこまでテストするか問題はすごいむずいなと思ってて例えばですけどこれ貴重面な人ほど沼にはまるんじゃないかなと思ってるんですよそうですね例えばなんかバルクインサートみたいな処理あるとするじゃないですかはい

これをテストする際に例えば3件一気にデータ作ってそれができてるかどうかチェックしますみたいなデータベースもっかかせずにデータベース実際使ってテストすることもあるじゃないですかないですかないかなまじかあんのかな単体テストレベルですかそうです設定変えると普通にテスト用のデータベースにアクセスしてテストできるじゃないですかそういうことですかそれはありますねで

じゃあ実際にこれが3件データ作られてるのかっていうのは多分チェックするじゃないですかバルクインサートだったらしないどうするんだろうなインサートだけですかいやするなするよなしますねはいおそらく貴重面な人になるとじゃあその3件がそれぞれ内容正しいもので作られてるのかとか見たくなっちゃうと思うんですよあーはいはいはいはいはい

でなんなら例えばもともとデータベース5件あって8件に増えてるかどうかとかもチェックしたくなっちゃうと思うんですようんうんうんうんとかなんかその辺じゃあどこまでやんだろうみたいなそうですねえっと僕が最近読んでたはいあのグッドコードバッドコードとか単体テストのなんて本だっけ考え方なんとか方あーなんとか方はなんか

みたいな本 樋口 塩分方みたいな感じで聞こえちゃう 深井 自分なんとかの方法の方ですねよく言われるのは基本的にテストの観点ってさっきも言った通り失敗してる時だけに引っかかるテストを書くですねなのでテストコードの中の一部を例えば変えた場合 幾分の論理条件変えたりとか定数の値変えてみたりとか

この辺の失敗してる時だけこけるように朝音をかけるようにするのがいい単体テストだとされてますなるほど中身かデータベースの中身が合ってるかっていうのがそのメソッドの責務かどうかですよね

なるほどそれはもうORM使ってるならORMじゃんとかそうですそれはそう思うんですよね下手したらインサートするバルクインサートする単体テストを書く場合はデータベースをモック化してデータベースの引数にその値を投げてるかだけでいいかもしれないですねなるほどね本当はただその中身をどんだけ見るかですよねどんだけ見るかな

ぶっちゃけそんなに見ないんだよな俺はその辺も結合テストになるのかな結合テストになる気はしますよね単体で見るべきことじゃないかデトロイト画家で言うと単体テストと結合テストが結構ふわっとしてるんですよそうなっちゃうよねでも結合テストってだってそういう感じだもんなコントローラーのテストでモック化しないみたいなイメージそうですそうですそうです

そこを結構ふわっとさせてるのがデトロイド学科の方で割とデトロイド学科の方でTDDLっていうのはもうBDDって言われるBehavior Driven Developmentですかそうですそうです車行く道って言って結構結合テスト的にものを確認してるようなことになるなと思ってるのでぶっちゃけ動ければどっちでもいいんですけどなのでそうですね中身そんな見なくてもうんうんうん

いやまあ見るかなどうなんだろうないや見たくねえめんどくせえめんどくさいんですよねわかるそれはめんどくさい大事なとこだけ見ればいいなって思っちゃうなうんまあなんか入力するものがうんもうすでに変数であるんだったらねはい普通にサクッとボーンって入れれますけどあーまあ確かにただなんかメソッドの中でなんかデータのデータの加工とかをやっててうんうん

ストリングとかにしないとストリングとか配列わざわざ一回ベタッと貼って作らないとデータベースの中身と同じものを用意できないとかだったらサボっちゃいますなるほどでもなんかデータの加工してたらその加工のテストは責務に入りそうな気もするんですけどそうですね確かにそれはそうだそれはおっしゃる通りですねその時はちゃんと見なきゃいけないですね引数に渡すやつをなるほどねはいはい

っていう単体テスト談義がありまあでもそんな感じでアサートっていうのはまあいろんな形じゃないですねいろんなパターンでアサート確認をすることができると思うのでまあ自分の

違うな単体テストをする上ではおおむね文字列というか値の比較とあとはMockをどんだけ読んだかとかMockにどういう引数渡してたかなあたりを多分気にするのが一般的だと思うのでその辺中心にどうやってどういうメソッドを使ったらそういうのを確認できるかなっていうのを見てみるとアサート部分の習得はできるかなって思いますうんうん

はいというので以上アレンジアクトアサートでよく言われる機能を紹介してみました確かに単体テストだいたいそれでカバーできる気がするこれを意識して勉強するとすぐ理解できると思うのでぜひぜひ単体テスト触ってるとかいう人はこの辺意識しながらライブラリを触ってみると

多分こういうことやーってなると思うので良い単体テストライフを送ってくださいっていうのでなるほど本日のお話でしたあとは細かい便利機能みたいなのがあったりするからその辺はドキュメント見てって感じですかねそうですねぶっちゃけ行動規約じゃないですけどチームのルールにも結構引っ張られると思うので確かにどこまで見るとかあと命名規則とかも特にそうですけどチームでどこまでやるかを今日

言うしながら多分やっていくんでしょうからちょっとPHPUnitだけなのかは分かんないんですけどコメントで挙動変わりません?ユニットテストってドックコメントのところにアットマークみたいな感じでアノテーションつけたら挙動変わりません?アノテーションつけて挙動変わるのはありますねあの辺僕最初ハマりましたねコメントで動き変わるんだみたいなPHPだとコメントなんですね

他だと違うんですか多分違うんじゃないですかジェストはよく分からないですけどPythonのPytestはちゃんとコメントアウトじゃなくてデコレーターって言ってアットマークはじめで書くなんかちょっとまた別の書き方なんですけどコメントアウトではないですPHPユニットはコメントアウトドックコメントのところにアットマークグループとかつけたりとかそうなんですねするんですよねへー

びっくりしたよなそれはコメントで動き変える間違えて入りられないかアットマーク作る的なのはあるからその辺はあれだけどへー面白いちなみに今回話した話でも漏らしはあるんで例えばアレンジはパラメータ設定できるみたいないろんな

パターンで引数渡してテストしたい場合あるじゃないですか例えば教会一文活とかでだから教会一文活って言ってるのは1万円以上なら送料無料っていうテストがあったら9999円だとできそれじゃ良くないわ例が良くないです例が良くなかったです複数パターンでやりたいの複数パターン

上限と下限があるやつですか違いますねユーザー登録をするときにユーザー登録をするテストでユーザーデータを投げますと男でも登録できるし女でも登録できるというのを見なきゃいけないというテストがあったときにテストメソッドを2つ作るんじゃなくてパラメーターを複数パターン渡して同じテストをしたいとかあるじゃないですかありますそういうのもアレンジのところアレンジなのかな

テストメソッドの範囲でパラメータを複数パターンで渡せる機能も多分あったりするのでこれはもうアレンジアクトアサートの外側だったので今回ちょっと喋れなかったんですけどそういえばそういうのもあったなとかいろいろあるのでそれはまあドキュメント見ながら勉強してくださいって感じですね確かに今もう僕が知ってる全ての機能出た気がします僕もそう思います多分大体こんなもんですまああの

モックとかで結構いろんなリッチな機能がいろいろあったりしますけどねあとはテストのコンフィグの部分とかセットアップの部分別のファイルに分けるとかそんなこともあるんだ物によってはありますでもそんなライブラリー個別な話なんでここではやりませんたまに単体テストのことを思い出しながら仕事をしたいのでたまに単体テストの話を入れていくラジオでした

テストなぁ繰り返しやんないとやっぱ人間定着しないんでいやそうなんですよねなかなかやんないんですよねやっぱそうですね和田さん曰くテスト駆動開発してるとベロンベロンになってもバグのないコードかけるらしいんでお酒でってことですかそうそうそう

なんだっけなツイッターで見たんですけど夜酒を飲みながら行動を書いて記憶がなくなって朝になったらソフトウェアが一つできていたいやいやいやおかしいだろ

どういう状況TDDなら記憶がなくてもバグのないコード書けるみたいなあのあれですよねテストコードはシラフの時に出来上がってるってことですよねいや違うじゃないですかTDDなんでコード書こうと思ってテストコード書いてレッドグリーンリファクタリングを繰り返してだからテストコード正確テストコードは酔ってても書けるだろうってことなんですね多分そうだのそういうことか

酔ってたらテストコードごと変なの書きそうだけどないやもうなんなら画面見えないっすよいや確かに焦点合わないっすそれはちょっとね面白話すぎるいやでもやっぱりね上級エンジニアというかねトップレベルになるとそうなるらしいんでマジかはい

そこを目指してそこは目指さなくてもいいかもななんだっけなめっちゃ別な話ですけど和田さんのその話も僕が普段聞いているハライチのターンの澤部さんが芋焼酎飲みながらレゴブロック組み立ててたら恐怖がなくなって起き上がるとレゴができてるみたいなそれと一緒だなと思ってツイッター見てて全然レゴも意味わかんないけど

レゴってできるもん何も繋がるだけやね あれなんですよね商品があるんですよねレゴってはいはいはいはい 忍者のお城みたいなはいはいエジプトのエジプト編みたいな あれがなんかできてるらしいです芋焼酎飲んでると マジで記憶そんな取り方したことないかな 記憶飛んでる時って寝てるっすもんね記憶飛ばしがちの人なんかそうなんかもしれないです なるほどね

はいというわけで30分になりましたし終わりますかいつもの宣伝ですねハッシュタグひまじんプログラマーでツイッターでフィードバック募集してますので気軽にフィードバックお願いしますどしどしお待ちしております僕らのモチベーションになりますので本当にお願いしますあとは説明欄にあるGoogleフォームからポッドキャストで話してほしいこととかお便り募集してますので何かありましたらそちらからお願いします最近ちょっとね

競争率が上がってますから確かにそうですね早いもん勝ちですよそれではエピソード終わりますまた次回バイ