この番組は駆け出しエンジニアの順平と先輩エンジニアの海地篠里が送る駆け出しエンジニアを中級エンジニアにキャリアアップさせるラジオですやっていきましょうお願いしまーす今日は僕の仕事の中の悩みというか永遠の課題永遠の課題についてちょっと議論したいって話ですなるほどね仕事か家族かみたいな違うそれも話したいかもしれないけど違うはいえー

ざっくりテスト戦略っていうのかなテスト戦略についてちょっとお話したいんですけどユニットテストインテグレーションテスト結合テストか結合テストシステムテストとかE2Eテストとかありますけど今回話したいのはユニットテスト広い意味で広い意味で広い意味でって言ってるのは古典学派古典学派

的な意味メソッド単体ではなくてMockを使わないでいろいろ呼び出す結合テストユニットテスト結合テストとE2EテストGUIから投資で実行するテストの2種類についてどこからどこまでをどこで担保すべきなんでしょうねっていう永遠の課題があって僕の中の

なんかみんなどう思うっていう話ですなるほどいいでしょこれってどうやって話したら話しやすいですかじゃあ順平お願いしますって言っていいですかいややばいですねやばいかもしれないいやでもそうそれしかないですかね僕から言うのでもいいですけどでも僕はでもなんかこの話題考えたぐらいなんで多分ボリュームあるっすだからいやなんか考えがなもしくはなんかわからないこととかでもいいですねなんか

ありますよ僕分かんないこといいですよじゃあのりさんからいきましょうかテストやるにあたって僕だいたい今のプロジェクトもそうなんですけどこれまで入ってきたプロジェクトもだいたいレイヤードアーキテクチャみたいな感じになっててだいたいどこも4層ぐらい

はいはいはいコントローラーみたいな層があってドメインロジックやるサービス層みたいなのがあってあとデータベースとかにアクセスするインフラ層的な部分があってうん

あとビューか表示の部分はビューがありますよみたいなそういうレイヤーで分かれてるアプリケーションが多かったんですけどこういうアプリケーションってコントローラーからサービスを呼んでサービスからモデルなりリポジトリなりを呼んでっていう構成になってるじゃないですかっていう時にじゃあモデルのテストとサービスのテストが両方ありますよと果たして

どうするかっていうかサービスからモデルを呼んでるからモデルがぶっ壊れてたらサービスぶっ壊れるじゃないですかっていうことを考えると果たしてどういう区分けでテストすればいいのかみたいなのはめっちゃ悩んでました悩んでましたというかテストやってないんで悩んでないんですけど笑

やったら悩みそうだなと思ってました意識高いですよね現場をリアルに想像して勉強してる段階で悩むっていうそうなんです意識が高いんです意識高いですねすいません分かるな分かるもっと言うとコントローラーもテストしようってなったら同じことが起きるじゃないですか結構悩みどころではありましたうんうんうんうん

わかるでもいいかな勝手な話広げていいですか一旦その前に僕の持論を言っていいですかお願いしますまずコントローラーのテストに関してはMock等々はしなくていいんじゃないかなと思ってます一方で中のメソッド呼び出しとかも別にテストしなくていいんじゃないかなと思ってます

なのでコントローラーが受け取る入力のパラメーターを変更してその結果期待したレスポンスの型とステータスコードをチェックするサービスはぶっちゃけMockするかしないかは

際どいところではあるんだよなうんうんうんなんか場合によっては普通にサービスのテストでもうモデルの中もチェックしちゃうようなのを書いちゃってもいいんじゃないかなって思ってる時期もありましたうんうんうんうんなんか結局テストできてんじゃねみたいなうんうんうんなんか一方Mock使ってじゃあモデルと切り分けてやるってなったらちょっとめんどくさいなって思っちゃってましたうんうんうんうんわかるっていう感じの流度で言いますいいですありがとうございます一個質問なんですけどはい

コントローラーのテストするときにレスポンスされる数字とレスポンスの型だけ見るみたいなこと言ってましたよね型っていうのは例えばコントローラーだとほぼWeb APIのレスポンスみたいなのが返ってくるわけじゃないですかなんで

ストリングじゃないですかボディってだいたい片手あれでしたこのデータが入ってるかどうかみたいな的な方のJSONだったらユーザーが含まれてるかどうかみたいなそういうことですね例えばRESTだったらユーザーすら1でゲットリクエスト飛ばしたらユーザー1番のデータが取れてほしいじゃないですかそれがちゃんと取れてるかどうかみたいな

じゃあボディの中身見るってことですねそうですねわかりましたわかりました形状ですねJSONの形状ありがとうございますそのまま一旦僕も言いますねノリさん今バックエンドの話だけしましたバックエンドの話だけしましたフロントはちょっとわかんないですねフロントはむずいなフロントぶっちゃけ

自動化したことないしイメージもついてないですね一旦バックエンドとフロントを分けるのはこの話する上で大事なんで一旦バックエンドの話だけするんですけどこれも僕も何でしょういろんな本を読んで自分なりの考えなんですけど基本的にMockは使わないですコントローラーからテストするとして

多分コントローラーというかそうですねコントローラーAPIでいうエントポイントによって複雑さ違うじゃないですか例えばゲットとかだと多分中で条件分岐そんなないのでそういうのはコントローラーから全部やっちゃいますわ裏のサービスとかモデルとかポストとかプットになるとなんかいろいろあるかもしれないんでそれであまりにも中が複雑になるようになったら

コントローラーからもテストするし裏のサービス単位でテストコードを書いたりもしますね二重で検証されることはあるかもしれないですけどそういう時はコントローラーの方のテストめっちゃ荒くしますね正常系1個だけみたいな具体的にどういう風にサービスの方のテストとコントローラーの方のテストで分けるかっていうのって温度感難しいかもしれないんですけど

そこは僕カバレッジ見ててテストの結局カバレッジで通ってればいいかなとB1分岐かなC1分岐だっけC1だった気がするはい

っていう考えでやってますねなるほどC1とC0となんかあるじゃないですかありますね分岐モラ条件モラどれがなんだっけ一応調べましょうですね分かったかもしれん命令モラがif文があった場合例えばif条件1だったら条件の1処理するその後続の処理があるってなった場合に

if文の中が通ってればokみたいなうんうんうん通ってないケースはテストしなくても網羅できるのが命令網羅C0はいC0分岐網羅がそれぞれの条件判定における審議が少なくとも1回は実行されるだからさっきみたいなif文があったときにちゃんとtrueとfalseの両方がチェックされてるかどうかうん

if文の条件をちゃんとチェックするってことですねそうですね中身というか条件網羅がそれぞれの条件文における審議が少なくとも1回は実行されるようにテスト設計しますif文の条件が複数ある場合なおかつelseifっていうんですかif文が何個も連なっててそれぞれに2個ずつ条件があるときにめっちゃ分かりづらいんですけど

全部通ればOKなのがC1なんですけどC2は上が条件1に引っかかって下も条件1に引っかかってる場合とそれぞれ各4通り1 1 1 2 2 1 2 2っていう全部の組み合わせを見るっていうんですかねうんうんうん

それがC2カバレッジなるほどですね僕はテストするときそこまでしなくていいっしょって思ってるんでif文の条件だけちゃんと見れるC1カバレッジでちゃんとテストコードでカバーできてるねっていうのを見ながらテストをしててなるほどカバーできてるっていうのはテストコードを実行したときにそこが呼び出されてるからですね

で読み出すそれって100%になれるできるそこはじゃあ100%になったらOKとしている正直90ぐらいな気持ちですねなんかレアケースとかあったりするんですよあとめっちゃモックしなきゃいけないとかそういう時は妥協してますまあいっかって

でもだいたい100になるようにしますねシンプルにメソッドかけた時とかは本当に1個のアプリ作っててたまにそういうのがあるんでそういう時は頑張って追いかけないそういう時は最悪外血とか別のテストレイヤーでカバーできればいいかなぐらいの気持ちですね障害テストとかちなみにMCCっていう鬼のパターンもあるっぽいですね本当に誰使ってるのそれ

これはあのU文が例えば2個あった時にトゥルートゥルートトゥルーフォルストフォルストゥルートフォルストフォルストの組み合わせをテストするみたいなうんうん

だから何乗だ?ヤバいですよね結構ヤバいですねこれさっき言ったコントローラーの処理を考えた時にコントローラーの一通りの処理で何個if分あるのって話ですもんねif分だって3つあっただけでテストパターン8になるから2の3乗とかそういう何乗とかで増えていくね爆発するだからメソッドごとに分けるんでしょうけどにしてもヤバそう

まあみたいな考え方ですだから基本的にコントローラーからできるのはやってでうわぁこれサービス結構複雑になったなーっていう時はサービスごとにやるというかあーなるほどねはいユニットテストというかそうですね確かにそれで言うとさなんかよくテストの方でカバレッジはまず100%に別に目指すもんじゃないみたいなやつとあとなんだっけなあのーあ忘れた忘れたー

思い出せないから一回巻き戻していいですという感じでやってますねここから僕の前どころの画面側なんですけど画面どころで悩んでたんですね画面悩むんですよね何悩んでるかっていうとめっちゃ極端なこと言うと

画面の動きって言いついて人で全部カバーできるんですよ全部できるのかなほぼ全部ちゃんとやってればってことよねちゃんとやればちょっとソフトウェアの作り的に異常系できないのあるかもしれないですけどねなるほどねDB止めるみたいなそういうの抜けば全部できるんですよ例えば物件検索思い浮かべていただいて

すごいですよ物件の検索のチェックマークの量あれはすごいですね実装するとなったらゾッとしますE2Eテストであれ全部検索しようと思ったら例えば大宮駅で検索してこの期待したやつが出るよねでテストした後にじゃあ次ABCわかんないけどなんか許可されてない文字入れて検索してなんかエラーが出るよねって検索して

とかあと大宮駅徒歩10分かもしれないし徒歩5分かもしれないしその151、3、20、3060分以上みたいな全部やるとか確かにあと範囲とかも組み合わせありますよねそうですね家賃とかだったら下限と上限両方あるパターンとか下限のみとか上限のみとかどっちも同じとかですですですでそれをバカ正直に言いついテストすると多分死ぬまでかかる

極端かな相当でも組み合わせ爆発してますよあれすんげー時間かかるんですよ今のは不動産検索だから極端かもしれないですけどよくあるポータルサイトとかでも多分そうなんですよね度合いは違えどだからE2Eテストのシナリオって減らすべきってどの本でも言われてますシナリオとは

シナリオとはテストケースですねさっき言ってた大宮駅で検索するっていうユーザーがやる一つのストーリーというか流れを今シナリオって言っちゃったんですけどだからそれは最小限すべきなんですよこれ言い継いテストについては軽く触れておかなくて大丈夫か触れたか

じゃあ触れておきましょうかエンドツーエンドテストって言われるものでユーザーが触れる画面からバックエンドの全てのシステム全部繋げてやる本物動かしてやるやつ本当にユーザーが使うようにテストするってことですよねそうですねっていうのが厳密にE2Eの定義なんですけど最近触れてる僕が触れてるプレイライトっていうフレームワークこれE2Eテストフレームワークって言われてて何ができるかっていうと

セレニウムみたいなみたいなっていうのもあれですけど画面操作してくれるやつRPAみたいなプログラムでブラウザー直接操作してアプリ動かしてくれるんですけどとはいえバックエンド別にモックするんでプレイライトもだからなんか本当の意味のE2Eテストっていう意味でE2Eって使われてない気もしてますここ半年プレイライト触れててそのモックは必須されるんですか

いや必須ではないんですけどただ多分全部つなげてテストしてるプロジェクトあんまないんじゃねってちょっと思ってます激おもになる激おもというかフロントエンド開発してプレイライトのテスト書くんですよ結局機能追加した後にそれって自分のプログラムだけでやるんで対抗システム使わないんでテスト回すとき普通それって多分厳密に言い継いテストじゃないはずでも言い継いテストとして

言ってるプロジェクトが多そう世の中画面から動かすものを言いついてると言ってるかもしれないなるほどねそこは僕の中でもふわっとしてるんですけど世の中こう言ってる人もいるなと思ってます正しくは内部結合テストですね厳密に言うと顧客

それはでも顧客用の環境ではん?違うな顧客の環境に似せた環境っていうこと?いやまあ似せた環境って言い方が似てるかもしれない顧客想定環境まあ普通にウェブアプリ動かしてる環境ウェブ環境そうかじゃあ俺もそうかなうんなんて言うんでしょうその本物使ってないこと部分があるっていうんですかねあーはいはいはい

バックエンドは本物を繋げるかもしれないけどそのバックエンドから呼び出しているものは本物じゃないかもしれない監視とかが本当に入ってないかもしれないとかあーはいはいはいそれはないかもでもこれは僕から見えてるだけなんでちょっと世間どうなってるかは普通に知りたいっすでなんでその言いついテスト画面から触るテストのテストケースって最小限にすべきうん

どこまで減らすんでしょうねっていうねでクソ悩んでてでこれって僕が最近思ってるのは結局その作ったものを受け取る人次第かなと最近思っててですね作ったものを受け取る人次第そうです例えばそのSUMOの不動産検索サイトで言うとプロダクトマネージャーなんですかねあーなるほど

ユーザーじゃなくてそっち側ですね多分そうですユーザーじゃなくて品質としてOK出す人っていうんですかなるほどなるほどこのぐらい試してくれたらいいよっていう合意次第なのかなと思ってて住宅開発でいう受け入れテストやる人みたいな受け入れ側ですねですですです例えばさっきのSUMOのやつとかって本気でマジで全組み合わせしたら終わんないんですよ

ただ1個ずつやるんだったらまだ現実的めっちゃ多いけど1個ずつっていうのは1項目それとも1バリューずつ1項目ずつやるんだったらもっと少なくなるし例えば全部一気にやるだけでいいよかもしれないですし全複合を一発ドーンってことそうそうそうそうそうそう

その合意の取れ次第かなってちょっと最近思ってて確かに言いついテストって画面動かしてやるしあとスナップショット撮ったりするんですよ画面の本当の見た目のスクショは撮れるんですけど何が嬉しいかっていうと思ってる見た目になってるかなって見れるのがいいんですねだからデザイナーがいる場合とか

エラー文がこの位置にこの色でどういうフォントで出るかとかそこまでチェックしたい前期のチェックしたいだって言われたら困っちゃうんですけどエラー文も1個だけ見れればいいよねかもしれないじゃないですかメッセージ変わるだけだしみたいなそうそうそうメッセージ変わるだけだしもっと言うとエラーなんてあんまり出ないからスクショで取るまでもなくてHTMLとして出てるのが見れればいいよだけかもしれないですしうんうんうん

っていうのであくまで品質をOKって管理してる人の合意が取れるぐらいのテストをかければいいのかなっていうのが最近の僕の考えでそうじゃないとマジで終わんないんで本気で数十分数時間かかるなんでスナップショットテスト言いついテストはマジで正常系だけマジで正常系だけにして

エラー文とかが出てるよねはユニットテストJavaScriptでいうとJestあとなんかあった気がするけどあの辺でメッセージが出ることとかそれだけ担保していく感じにしましょうねっていうのを品質管理してる人と話をして説得していくっていうんですかねなるほどねあれですよね

説得していくの大事ですよねそうですね向こうが完璧に持ってるとは限らない気がしててそうですねしかもそういうのがないと開発が勝手にやった品質ちゃんと管理できないダメダメチームだって思われるんでいやいや合意取ってますよみたいな誰かのせいというか責任を共有していくのがすごい大事な社会人スキルな気がする確かに

E2Eテストはあくまで正常系だけマジで1画面1とか2だけにしてあとは残りのバリエーションはユニットテストとかでカバーしていくのがいいのかなっていうのが最近の僕の流れですなるほどねそれでいうと疑問で言うと僕はフロントの単体テストもちょっと何をテストするかよく分からんちゃ分からんすよね

あれなんですよねジェストとかだと表示してるHTMLというかDOMとか取れるんですよその中身に例えばエラー文ユーザーが重複してますとかエラー出したいときに重複してますというメッセージが含まれてるかこのHTMLの中にとかこのタグの中にとか

っていう形で見た目はテストしていくことが多いですねエラーメッセージだったら例えばこの赤くするためのクラスが付いてるみたいなそういうのもやるんですか?ですねですねもし確かめたかったらですねそんな感じですただどこまでちゃんとやるかはだからマジでプロジェクト次第ですけどねエラーなんて多分全ページで使えましたと思うんで

多分エラーのコンポーネントエラーメッセージコンポーネントのか分からないけど3位とかで多分チェックするんでしょうねコンポーネントに対してこういうプロパティ渡せるように作ってるんだったらそれを渡した時に期待される形になるかどうかをテストするってことかそうですねそれもさっきのバックエンドと同じで基本的に画面全部でやるんですけど使い回してるとか

なんかバリエーションいっぱいあるやつに関してだけなんかコンポーネント単位とかでやる気持ちですね今はなんかすごいコンポーネントでやってればすごいわかりやすいけどそれこそビアクトとかUGSが出てくる前に作ってた本当にJQueryみたいでやってるページとかってもう単体テストとかしようないですよねわかんないどうなんすかね1ファイルで全部書かれてるみたいなファイルごとにあるのかなでもそうですよねうん

その時どうだったんだろうねそれこそプレイライトとかなかったはずなんでJQでアプリ作ったことないからなどうするんでしょうね人力じゃないですか人力かもしかも自動は諦めて手動でやるか手動な気しますよね多分なるほどっていう感じです本当にプレイライトって

ページ開いてそこスナップショット撮って終わるだけでも1シナリオで多分6秒7秒かかるんでそれで100あるだけで十数分かかるし画面重かったりするともっとかかるんでスナップショット撮ったりとかするのにそんなのねCIとかに時間かかってるとテストとかに時間かかってるとねそんなアジャイルに動けませんからそこシビアに行きたい

それはなんか並列でとかっていうのはあんまりないんですかそこまでやろうっていうのはできるんだけど並列って結局平行じゃなくて並列だよねだからCPUのプロセッサ数が限界なんですよ例えばあの何GitHub ActionsとかでCIやろうとかって思うとそんなねCPUプロセッサめっちゃ乗ってるインスタンスいちいち立ててるとすんごいお金かかるしローカルのMacとかでもこれ何個なんですかねちょっとわかんないけど

そんなだからめっちゃ多重にできるわけではない並列Aはやるよもちろん並列でやってるけどそれでもなかなかに時間かかるですね結構かかるマジで何も考えないでめちゃめちゃ組み合わせちゃんとやるとね数時間単位でかかると思うわかかりそうE2Eテストは数時間単位でかかると思うもちろんアプリケーションの性質にもよるでしょうけど

僕がやってるわけじゃないんであれなんですけどオートスケールして並列でロードしてるのかなテストの時だけそれでも結局めっちゃお金かかるって話ですよねたぶんかかるかかるかかるかかると思うよめっちゃかかるでももちろんチームの資金力にもよるよそうですね

なるほどそれでそうですね時間は短縮しようとはしてるっぽいですね短くはなるもちろんしかもさもともとが長ければ長いほどインパクトでかいですよねもともと60分だったら30分にしかならないから30分しか縮まらないけどもともと12時間かかるんだったら6時間縮みますからね2倍に増やすと確かにそれが出かかったりはするかもしれないね

基本手動で今のところずっとやっててなんとか自動化しようっていう流れではあるんですけど素晴らしい項目的にいくつだろう400項目ぐらい手動でやってるのかなテストやっぱそれをMacのChromeWindowsのChromeWindowsのSafariでやってるんでWindowsのSafariはOSにじ曲げてるわ多分WindowsのEdge?

エッジです3パターンでやってるのでなかなかに時間がかかるんですよかかるよねなので項目はできるだけ確かに減らしたいっていう気持ちで僕はやっててでもなかなか

一緒にやってる人というか分かるとかはそれ追加するんだっていう風に思っちゃったりも正直しちゃう分かる書いたことによって今後もそれをやらなきゃいけなくなって

分かるそうだよね変えちゃったかってなることがよくあります正直分かります分かりますやりすぎテストみたいな感じですか僕はそこいらないんじゃないかなって思っちゃうし今後の負担を考えたら本当はない方が幸せでもテストの観点から見たらないに越したことあるに越したことはないんですけどっていうのを思いつついつもうーんって正直なっちゃってますね僕結構やりすぎるんですよ性格的にでなんか

転職してチーム変わって今のチームでテストとかやってて本当にバラバラだったんですけどもともと人によってはこんなやらなくていいんじゃないって人によって機能を作るときにテスト書くんですけどテストの理由が違うんですよ人のコード見ててこの人俺にこんなテスト書かなくてよくねって思ってそうだなっていうのを察知したんでなるほどねそれで今日の話題につながってる

そうですね僕はそこを結局僕も別にテストしたいわけじゃなくて品質が担保できてて最小限にしたいだけなんでチームで話し合いの機会を設けてここからここはユニットテストでやってるからE2Eテスト適当でいいよねみたいなそういう会話をして初めて僕もここは適当でよくてここはちゃんとやろうみたいな区分けができるようになりましたね

すごいいいフィードバックされてるなうん順平がそこまで動けたら最強ですねすごいないやーなんかそういう認識合成の場をすることはあるんですけどうんそれってなんていうか全体の方向性を決めるのがいつも難くて結局項目ごとの確認になっちゃうんですよこれがいるいらないって話になっちゃうんですよねになっちゃうんですよね全体的にこういう方向性で行きましょうってなっても結局なんかうん

そうなんだよその方針というか抽象的に整理してくれる人がいないんですね多分もしくは何て言うんだろうなでもそういうことだよな抽象的に意識合わせる営みまでいけてないってことだよね多分ね具体的な話になっちゃうじゃあこれどうなのみたいな法則みたいなものを生み出せないで終わるみたいなそうですねそうですね生み出せない

生み出せないプロジェクトは別にないのかなどうなんだろう生み出せないプロジェクトな気もするんだけどなそんなことないのかなちょっと考えきれてないかもしれないそこ全部できるとは言えないわ多分

できないのはありそう例はわかんないけど他にも一回デグレしちゃった場合とかはその項目って今後もデグレする可能性があるからやっぱずっとテストしていくべきなんですかねそれはそう思う絶対にイエスだと思うそれは絶対にイエスただそれはE2Eテストでカバーするんじゃなくてユニットテストでカバーするでいい気をするね教科書的なことを言うと

そこもちょっと迷ってたんですけどそれはそうかそうなんですよ

ちなみにどこまでテストするか問題も結構むずいなと思っててテスト系の本とか読むと壊れやすい箇所と大事な箇所はテストした方がいいけどそうじゃない箇所は逆にメンテナンスのコストが上がるからそんなにテストしなくてもいいみたいなのあったりするじゃないですかはいありますね僕的にこれはテストいらないんじゃないかみたいな

場所でどうなんだろうって認識合わせしたいんですけど例えばさっきめっちゃ最初の方に説明したMVCにサービスを追加したようなレイヤードアーキテクチャでモデルのテストサービスのテストをする際サービスには例えば一件ユーザーを取ってきますよみたいな本当にモデルをただ呼び出すだけの媒介になってるメソッドみたいなのってたまにできるじゃないですかたまにとか結構できるイメージなんですけど

ああいうのってテストいります?どっかで通ってればいいと思いますコントローラーから呼び出しててコントローラーが通ってれば僕はいいと思いますなるほどじゃあ伝わります?サービス側ではテストしてないけど何か問題があった場合はコントローラーのテストでチェックできるようになってるみたいなはい個人的にはそう思いますなるほど通ってる必要はある気がしますねなるほどなんか全放置はうん

できないなんかめんどくさい気がするっすあーなるほどねあーめんどくさいかめんどくさいというかなんかあの言いついとかわかんないけど何かで起きた時にテストでどこ壊れてるか特定できないうんうんうんですよね全テストが通ってないならまあ言いついテストで通ってるかもしれないですけどなんかそのモデル呼び出しをしてるだけのさテストって要はフレームワークのテストしてるようなもんなんじゃないかなって思っちゃうんですよねうんうんうんうんそれはそうですねうんうん

ノリさんはそこは書いてるんですか?僕はテストまず何も書いてないんですけどもし書くとしたら飛ばすかなっていう気がするんですけどなんて言うんでしょうねコントローラーからも呼び出されてるんですよねきっとだから多分通るんですよね勝手に通るっちゃ通るレアケースでしか通らないとかだったら書かなくていい気もします

コントローラーのテストがあってサービス層のテストもあった時に大体あれ上からテスト作っていくじゃないですかメソッドに対してってなった時にこいつは簡単だからスキップしようっていう勇気って結構いるなって思ってるんですよねうんうんうん確かに気持ち悪いというかそれこそ一行しかないメソッドとかわざわざ書かないですねそうそうそうフレームワークの機能使ってるだけみたいなあーなるほどね

それ系は全体を通っているテストでカバーできてるからいいかみたいなそうですね気持ちはもしカバーできてなかったとしてもここ別に壊れなくないというか壊れたとしたらそれはフレームワーク作ってるやつらじゃねみたいなそうですねそういうのは書く必要はない気はしますねそれゆえのカバレッジ90%気持ちっていう感じなるほどためになります

いやなんかちょっとまた来年かわかんないですけどどこかのタイミングでもう一回話して別の話になったらまた面白いですね確かにはいっていうのでちょっと今日僕の業務上の悩みというかテストどこまで書くべきなんみたいなのについてちょっと話してみましたけどなんかちょっと聞いてる方で意見ある人いたら普通にマジで教えてほしいんで

そうですね出演オファーお待ちしてます出演オファー逆かな出演プロポーザル出演プロポーザル斬新ですね出演プロポーザル面白いなかつてのねホーネーソーボンバーさんやだけか

最初と最後の出演プロポーザルでしたけどみたいな感じでテスト詳しい方ちょっとお願いします普通に勉強したいです本読んでてもなかなかこの辺の話って出てこないんで確かに全員多分手探りでやってる感じっぽいですねうんうんうん

お願いしますどうしようかな締めちゃっていいですか時間まあまあいったんでそうですねでは最後ハッシュタグ今人プログラマーでSNSでフィードバック募集してますので番組の質問要望じゃなくてハッシュタグ何しようかなテスト系のやつ

じゃあハッシュタグテスト戦略で真面目資格試験のテストに向けた戦略について教諭町にお話ししますそっち?期末テスト?はい期末テスト向けね意味わかんないねもう関係ないですからねエピソードにねそして今夏休みですからね一番期末テストから遠い時期その層聞いてないって多分そうか確かに大学生いるかもしれないけどねであとは

ポッドキャストの説明欄から番組の感想要望質問何でもお待ちしてますお気軽にお願いいたしますテストの僕はこう思いますとかぜひお便りでもいいのでお願いしますお願いしますめっちゃ気になりますあとポッドキャストプラットフォームでのフォロー高評価お待ちしてますこちらもお願いしますいいねを押してください

たくさんお待ちしていますはいちょっと今日はふわっとした話題になりましたが僕のいいアウトプットになりましたしちょっといろんな人の話を聞いてなおかつちょっと知識が深まりましたありがとうございますこれで僕もテストしてる風で話せると思いますいや行きましょうもう本当にテストしてるキャラ面白いですよテストしてるキャラ今まで一回もしたことないのに

めっちゃ語るのに現場ではどうしてるんですかいや書いてないよ一回も書いたことない今日だって途中でのりさんテスト書いてるかっていう気持ちになりましたもんそういう気持ちにさせたいと思いながら日々生きていますいやいいなめっちゃ面白いな本人的には気が気じゃないかもしれないですけどそうですよドキドキですよこれ外野から見るとクソおもろいですね

やってる人よりも語ってほしいマジでこだわりとかそうなりたい本は読んでるはいじゃあのりさんのテスト語りエピソードお待ちしてますはい頑張りますはいバイバイバイバイ日本のエンジニアは使うアプリが多すぎる事実ひまプロの使用アプリ平均数38.6個レイキャストならアプリの即起動過去のコピー履歴を引き出せる

ウィンドウのリサイズなどこれ一つで作業効率アップしかも料金無料今すぐレイキャストで検索