この番組はエンジニアの成長は楽しい学びからをモットーにエンジニアリングに関する学びをワイワイお届けするラジオですということで本日お便り会になってますありがとうございますじゃあお便り読みますラジオネームゆううさんゆううさんはい、あの、ハイフンじゃないにょろにょろにょろのなんて読むんだっけこれチルダにょろにょろゆうさんからのお便りです

感想からいきますいつもポッドキャストを楽しく拝聴させてもらってますありがとうございます特にテストの回はとても興味深く現在フルスタックで開発しているもののE2Eテストはログイン機能を入れたタイミングでログインしたら目的のページに表示されるくらいのハッピーケースしか書いてないのでもしかするとテストサイズごとの比率が違いそうだなと感じながら聞いてました

テストを書くといえばT和田さんのイメージなのでゲストを迎えてたくさん質問するかいとかも聞いてみたいなと思いましたテストに関するディープな話は興味がありますということで感想をいただいてますありがとうございますそしてそんな中ちなみにハッピーケースって一般的な言い方ですか言うかなまあ土定番の一番正常系ですねハッピーなんだハッピーだな確かにハッピーパスって言うかもハッピーパスって言うかなハッピーパスって言うなうん

テストケースのケースでもまあ何とでも言いそうな気がしますけど正直何かの本で見た覚えはないです僕は現場で聞く本で読んだことあります?テスト系の本でちょっと弱って言いますかハッピーパスだなやっぱエンジョイケースとかでもいけるですかねラッキーパンチもいけると思う

ラッキーパンチはバグですよねシュレディンガーバグみたいなそっちバグになっちゃった今狙うぞって顔してましたね狙いに行ってたよなハッピーパスだな多分正しいのハッピーケースって言ったら出てこないですねうん

でポッドキャストで話をしていることこれテストなんですけどなんとか噛み砕きながらいきます承知でございますお願いしますスモールテストについてお話を伺いたいですリアクトタイプスクリプトでフロントエンドを開発するときに処理の流れとしてコンポーネントとかいろいろ通ってバックエンドを叩きに行く感じになると思いますとで画面を表示する部分はいくつかに分かれたコンポーネント

をまとめて表示するヘッダーとかサイドバーとかメインコンテンツ部分を表示するようなものになっていると思いますがこんな時にスモールテストをしようと思った時にスモールテスト後で解説しますねそれぞれのコンポーネント例えばヘッダーとかヘッダーテストする場合にはヘッダーにロゴが入っているよねとかテストすると思うんですがじゃあそのヘッダーを含んでいるページを表示する時どうしますかと

ページが描画されるときにヘッダーとかサイドバーとかももちろん呼び出されると思うんですけどそれを確認するテストを現状書いてますとこれってスモールテストなのかなというところも引っかかってるとスモールテストかなというのも引っかかってるしページのテストでコンポーネントが呼び出されてるか

というテストをしているのもBDDっぽくないなというところがもやっているとBDDはいっていうのでこの辺ちょっとお三方のお話このモヤモヤについてお話を伺いたいですというふうなお便りをいただいていますはいなるほどね非常にあのなんか普段あんまり言わないんですけどエンジニア歴1っていう方からこういうお便りが来るのはすごいなと思いますすごいはい確かにえー

っていうのでちょっとお話ししていければなと思うんですがまずわからん単語いくつかあったかと思うのでその辺噛み砕いていくところから始めていきます噛み砕いてもう一回お便り戻ってトークテーマ設定して話すみたいなお、迷子流れまずスモールテストですねこれ正直僕はあまり現場では見なじみはないですがこれ何かっていうと

Googleが提唱し始めた新しい目の概念提唱しがちだからなGoogleはGoogleは常識にとらわれないというか俺らが便利なように勝手にルール作っていくタイプなんでそんな概念なんですけど今までってテストを思い浮かべた時にユニットテストインテグレーションテスト結合テスト

システムテストとかE2Eテストみたいな形でテストピラミッドと呼ばれる三角形各細かさごとにレイヤーが分かれているものがよく言われる基本情報とかではそっちが出てくる概念ですねこれって何で区切っている概念なのかというとテストする対象ですね

ユニットテストは一つのメソッドもしくはメソッドに閉じてるインテグレーション結合テストはDBとか

他のお隣さん結合してやるやつE2Eでなるとユーザーが使う全てのシステムですね自分たちが作ってるのと対抗システム含めとかそういったものが含まれるみたいな形でテストの対象テストするときに動かすものがどんだけ多いかによって分類が

変わってたのが従来のテストの分類だったりするんですけどGoogle Small Medium Largeという非常に分かりやすい概念で区切ってるんですがこれ新しい概念何が違うかで言うとあんまり変わんないんですけどあんまり変わんないんですけど実行時間ここをすごい大事にしてるっていうのがちょっと新しい概念かなと

思いますスモールテストミディアムテストってお便りが出てきましたけどGoogleの分類の中ではスモールミディアムラージっていうのでMacのドリンクみたいな分類がありますとアメリカナイズアメリカナイズ分かりやすい分かりやすいそれぞれちょっと細かく言っていくとちょっとなんか概念も細かいんでさらっといくんですがスモールはユニットテストですほぼなるほど

ネットアクセスもないしデータベースアクセスもしないしファイルシステムのアクセスもしないし外部システムも使わないしマルチスレッドとかもやんないしスリープとかもやんないし処理待ちとかね他のものをいろいろ使わないしテストの実行時間が合計で1分以内合計?合計なるほど

じゃあ一個一個が小さくても1兆個とかあったらそれはスモールテストではないとスモールテストとしてはちょっと改革考えようねっていうところですねそれがスモールテストでミディアムはサイズちょっと増えますよとで買い詰まるとデータベースにアクセスするインテグレーションテストですねほぼ確かにファイルシステムアクセスするとかただローカルホストでできる範囲にします

なるほどだからS3とかMock作れるんだったらいいんですけどローカルでMockできないような何かはMockならいいんだよななんていうんだろうそういうのを使わないですとMockするそういうのに対してはだから本番環境としか通信できないAPIとかそういうのは実際には

使わない形の結合テストこれがミディアムテストですね実行時間の制限としては5分ラージテストこれもうほぼE2Eですねなるほどスモールとミディアムではないもの大きいやつこれは時間制限はないですないんだない

無限にやっちゃえってまあしょうがないよねものによってはまあ確かにどうしようもないもんねそうですそうですでこんな感じで新しく似たような概念に登場させたGoogleさんなんでこんなことやってくれたんだというとですね昨今のソフトウェア開発の事情を踏まえてこういうのがあった方がいいんじゃないっていうので提唱してるらしいんですよどんな事情がCICDですCICDはい

この実行時間ってあるじゃないですかまさしくCICD導入してみるって人はなんとなく感じると思うんですけどテスト時間かかるんですよねちゃんとやればやるほどCICDのパイプライン組んでる時ってプルリク出した段階とかでGitHubだったらGitHub Actionsとか回してプルリクできる状態にする

まで待つ必要がありますとうんうんでテストめっちゃ増えてくるとで何も考えてないと下手したら30分とかかかるわけなんですよなるほどかかりますはいでそんなん生産性的に良くないじゃないですかうんっていうので素早く終わるテストだけはプルリクに回すとか結合テストはメインにマージするときだけにするとかうんうんそういった形でその実行タイミングごとにというか頻繁に確認すべきものは細かいテストでやってうんうんで

結合テストみたいなのはちょっと頻度減らすみたいな実行タイミングとかのコントロールのためにこのサイズ分けたっぽいっていうのでこれはなるほどと思いつつなのでだからユニットテストとか結合テスト言いついテストも同じかもしれないんですけど例えば僕Pythonでコード書いてたりするんですけど

スモールテストの場合はスモールテストだよっていうタグとかもしくはファイルごと分けてアクションズの中でプルリクの時はスモールテストだけにするとかそういう実行方法コマンドって言ってもらうアクションズなんてテストサイズごとに実行を分けるそんな感じでテスト戦略を作っていくそのためのテストサイズっていう概念ですとなるほど

なんか機能そのテストの何ですか重さというかこの機能めっちゃ大事だよねみたいなのでも実行時間が長いんであれば頻度を減らすような場所というかマージするメインにマージする時だけテストを回すとかっていう感じなんですね多分がっちり守るものではないとは思うんですよそれがもしめっちゃ大事でしかもめっちゃバグりやすいんだったら頻繁にやるべき

だけどあとはまあなんでしょうねちょっとバグりやすいかつ時間がかかるテストうんまあだったら本当はなんでしょうね他のなんかデータベースいろいろやらなきゃいけないとかうんはまあ結合テストになるべきででさっき言ってた5分の制限時間を超えるようだったら素早く実行できるような工夫を死ぬ気で考えろっていうまあそういう基準というかそのための時間なるほどねはい

なのかなと思いましたテストの実行時間って放置されがちだと思ってて全員がなんかちょっと時間かかるなって思いながら時が進んでいき

気づいたらすごい時間経つなみたいな確かに爆増しないからねそうそう微増していくんですよねインクリメントですもんねゆでガエルみたいな状態だよねまさしくゆっくり温度上げていったらそのままゆでて死んじゃうみたいな達人プログラマーですか達人プログラマーです達人プログラマーで言われる言い回しゆでガエル他の本でも結構出てくるんで覚えておくといいと思います

ゆでガエルはですねお湯に入っていても熱くなっているのに気づかないんでしょうっけそうですねいきなり熱湯に入れるとびっくりして飛び出ちゃうんですけど水の状態から徐々に温めていったら気づかずにそのままゆでガエルになってしまうっていうテストの実行時間も同じですね確かにはい

基準があると見直すきっかけになっていいねっていうこれテストサイズの話ですねもう一個BDD出たこれね僕もね分かってないですそれすごい不安です僕ものりさんが分かってないって言われるとすごい僕は不安になってくるんですけどすごいシンプルな話ですこれははい

TDDってあるじゃないですかこれテストドリブンデベロップメントですよねYesBDDBehaviourドリブンデベロップメントフルマイクド開発ですねTDDってどういう進め方で開発していくかというとレッドグリーンディファクタリングのループを回しましょうってよく言われますがこれ何かというとノリさんが以前の

エピソードでお話しした通りこうなるといいなぁみたいなテストケース書いてでテスト回してみてまあもちろん最初は実装してないから通らなくてでこうなるといいなぁって言ってでそのこうなるといいなに合わせて実装して通ったよっしゃじゃあ今テストが通ってるってことはこのテストが壊れない限りはリファクタリングし放題だって言ってリファクタリングしてうん

今このテストケースだけだと本当の仕様を満たさないからこっちのテストも書こうみたいな形でそんな感じで進めていくのがTDDなんですけどBDDはもっと抽象度高い感じですねTDDはユニットテストで書かれるものだと思うんですけどBDDは割と

E2EなんじゃないかなE2EのイメージありますE2Eテストで書かれるものですなのでE2Eテストってどんなことが書かれるかっていうとユーザーが使ってることってか使うことAmazonで言ったら扇風機ってフォームで調べたら扇風機が検索できることみたいなこれがE2Eテストの多分内容多分E2Eテストはもっとかな多分そっから

扇風機ポチるとこまで行きそうですけどそれがユニットテストだったら扇風機っていう文字受け取ったら検索した文字列返すことみたいなそういう風に流度が異なるんですけどなんでBDDはユーザーが定義したこと企画サイドとかが定義した要件定義書とか要件定義じゃないかもうちょっと細かい仕様ユースケース一覧みたいなそれがそのまま書いてあるようなフルマンに対してテストを書いていく

テスト書きながら実装の検証をしていくっていうイメージだと思ってますなるほど流度デカTDDってことですかそうですね流度デカTDDなんかそれってメリットあるのかなユーザーが求めているものをそのまま出せてなおかつ試験した結果がそのまま試験項目表というか品質担保するものとして発注者に出せるっていうんですかねうん

割とそのBDDのツールとして有名なのはキューカンバーっていうキュウリなんですけどキュウリというかキュウリの名前がついたBDDツールというかテストツールなんですけどあれもすごくて日本語でテストケース書くんですけどなんなら日本語でテストコード書くんですけどそうなんだその日本語で書いてたテストコードそのまんまHTMLで出して試験表というか合格不合格みたいなの出せる

ツール名はよく聞くんですけどどういう仕組みってずっと思ってましたあれなんですよ僕1年目発言場って休館場使ってたんですけど日本語でメソッド定義して日本語の裏で普通のプログラム書いてこの日本語を呼び出した時の動きはこうみたいなもう1枚噛ませるイメージだった気がする

っていうのがBDDですなんで振る舞い駆動ですね振る舞い駆動で開発していくのがBDDっていうのを踏まえてお便り戻るんですけどリアクトウェブアプリの画面を思い描いていただいてスモールテストをしたいですユウさんはスモールテストをしたいなと思った時にページTSX何かのページをテストする時にどんなテストしますかですねユウさんのモヤモヤは

ページ呼び出した時にヘッダーのロゴが見えていることサイドバーが表示されていることとかを確認しているのは果たしてスモールテストなんだろうかというモヤモヤを感じているのが優さんですと僕個人的に思うのはっていう風に進んでいいですか僕個人的に思うのはですね

まずこのページをレンダーしたときにサイドバーとかヘッダーが見えていることを確認するのはスモールテストではありませんまず何なら多分ね表示していることとかを確認するのはスモールテストではない気がしますねはい多分

UIのテストにおけるスモールテストまあもうちょっと僕ユニットテストで脳内変換してしまってるんですけど画面の描画とかあんまり見ないまあ見ることもありますけどもっと言うとなんだろうななんかヘッダーとかだとまあこの画像を読み込んでるかとかかもしれないですねまあなんならそこテストしない可能性すらありますねもううん

結合テストの方に回しちゃうというかなんならE2に回しちゃうかもしれないですねなるほどヘッダーとかってそんな変わんないじゃないですかロジックもクソもないじゃないですかヘッダーのロゴとかただそのヘッダーのハンバーガーメニューをした時にどんなメニューが表示されるかとかはユニットテストに回すかもしれないこのヘッダーハンバーガーコンポーネントの持っている項目っていうテストを

ユニットで書いておいてE2Eではそんなしない細かいこと見ないなので一旦それはスモールテストではない気がするっていうのが僕の思うところで一方でそういうページをレンダーしたときにヘッダーとかサイドバーが表示されていることを確認するこれは必要だと思うんですよ普通のウェブアプリって

いろんなページあるじゃないですかありますいろんな画面で多分いろんなページ全部でヘッダーとかサイドバーとかフッター出すじゃないですかこれをどうテストするかはマジでプロジェクトによると思うんですけど正直僕1画面だけでもいいんじゃないって思ってる派です大体なんでしょうねなんかE2Eで潰さなくても誰か分かる範囲

かもしれないしヘッダーが変更された時に全画面のテストやり直さなきゃいけないのもちょっとなかなかめんどくさいなともちろんウェブアプリの質によりますねそんなことあんまりないヘッダーとかサイドバーが変わんないんだったら見てもいいかもしれないですけどただそのヘッダー変えたせいで別のユーザー管理機能のテストが落ちるとかこれちょっと僕は面倒だなと思ってしまうのでヘッダーとかサイドバーとか振っただけ

見るテストも作っておいてあとはそのトップページでちゃんとそれらが出てるよねぐらい確認して他のページは飛ばしちゃいますねリアクトとかだと各ページでわざわざヘッダーとかサイドバーとか定義するんじゃなくて大元のルートTSXとか大元ファイルでサイドバーとか多分定義すると思うんで抜けない抜けないと思うんで僕はちょっと

サイドバーとかはこれめっちゃ好みですめっちゃ好みなんで正解じゃないんですけど飛ばしてもいいかなと思ったりしますねいちいちそれ確認してるとマジでサイドバーにメニュー足された時地獄見ますよ確かにそんな一個一個確認するんだテストの方法によります僕が今イメージしてたのは

でもそうですねサイドバーに何かの文字が表示されていることもあるかもしれないですしあとスナップショットスクショ撮ってテストするやつスナップショットも僕はあった方がいいと思うんで一個は全機能全パターン撮る必要はないんですけど各機能画面ごとにスクリーンショット一個一個撮ってるとサイドバーのメニューがポッて増えた瞬間に全部落ちるんでっていうので多分そういう意味だとスナップショット撮ってる場合は細かく見てるんですねなるほどね

難しい本当に難しいんですよめっちゃトレードオフで究極この画面のサイドバー漏れてるかもしんないじゃんって言われたらいやまあそれは可能性としてはありますよとまあそうですねどうやって呼び出すか分かんないんですけどどうやって作るか分かんないんですけどなるほどね例えばサイドバーだとあれだけどヘッダーとかってさ

一般的なページのヘッダーと申し込みフォームの時だけヘッダーでリンク遷移できないようにするみたいな感じで分岐してるパターンがありそうだからそういう場合に漏れる可能性あるよねみたいなそういうことかなでもそれはもう本当に申し込み作る人だけはそこの部分ちょっとテストしなきゃいけないっていう自覚を持ってレビューする人もそれで

2人突破したってのもしょうがないですね確かにちなみにカイスさんの言ってるユニットテストってどういうテストになってますかユニットそうですねそこがまた僕曖昧でしたUIのユニットテストちょっと分かりづらいなと思ったりしますね例えばですけどなんだろうなボタン押したら色変わるとかあるじゃないですかああいうののなんだろう

ボタンのロジックメソッド単位でテストするみたいなものをユニットテストで言ってますブラウザ上で動かしてとかではなくてジェストとかでコンポーネントだけ呼び出してこういう条件を外部から与えたら変わるよしみたいなテストをユニットテストと呼んでますUIに限らないかもしれないフォームの

1万以上だとエラー出すみたいなのがあった時に1万というかもっと複雑だと何でしょうね住所とかだと実在しない住所が入れられたらエラー出すみたいなちょっと謎のコンポーネントがあったとしてそのバリデーションちょっと複雑そうじゃないですかそのバリデーションのロジックだけだからフォームとかの単位ではなくてフォームの裏で動いている

フロントの

技術書を読んだ時にテストコードを書く部分あったんですけどイメージコンポーネントに引数を渡して変化する部分をテストしてるイメージありましたねボタンのコンポーネントとかだったらボタンの見た目共通化させたいけど中の文字違うよねってなった時にそのコンポーネントにその文字を渡してその文字が表示されてるかどうかのテストするみたいなそういう流度のテストを単体でやってたような気がする

それゆえ単体テストないところもあると思ってますパーツによってはコンポーネントによっては言いついだけでしか試されないもの例えばフォントとか本当わかりづらいなただ押されるだけのボタンとかなんだろうロジックのないやつチェックマーク

ただ見た目として出てるチェックマークみたいなやつとかボタン押してとかじゃなくてただ見た目としてあるチェックマーク分かりづらいなインフォメーションマークみたいなそれこそ普通に表示されてる文字ってそれに当たるんじゃないかなそうですね文字もめっちゃ細かく言おうと思ったらね多分フォントがどうとか文字のポイントとかあるんでしょうかね

そんなわざわざテストし始めたら終わんないわなそうですねなんでちょっとこれは自分でも怖いなと思ってる発言なんですけどUIに関してはテストピラミッドみたいなピラミッドなんないんじゃないかなと思いますバックエンドのテストだと結構ユニットテストが一番でっかくて上に行くにつれてどんどん縮んでいくみたいなのがあると思うんですけど

多分UIのテストについてはユニットテストはちょっと小さくて単一のコンポーネントにローカルで起動できる範囲だからGoogleで言うミディアムテストミディアムテストは多分ちょっとでかくてラージはまた小さくなるみたいな形になるんじゃないかなと思いますねそれがテスティングトロフィーってやつかそんなのあるんですかあるんですよテスティングトロフィーそんな感じの形してて

あとこの話フロントの人から聞いた記憶あるんでそういうことかもしれないちょっと調べません?ですよねめっちゃ気になってます今カイさん自力でもしかしたらテストトロフィーにたどり着いたかもしれないじゃあ僕が提唱したことにしようかそうだなカイチって書いてあるトロフィーあげようくれんの?嬉しいけどそれはそれでほんとじゃん

本当じゃん本当にそうじゃん本当にそうだった俺も今つながったわすげーすげー俺じゃあトロフィストです今トロフィーの再開発したよはいトロフィー再開発しました再発明かはいすごいなんでえーとまあいろいろ戻つまりなんでそのなんでしょうねスモールテストUIに関しては多分そのスモールテストはやっぱり大きくなんないんですねうん

なのでそのゆうさんスモールテストについてお話を伺いたいですページTSXいろいろ表示されるページに対してスモールテストしたいと考えているというところで

そんなになんかこだわってスモールテストする必要がないというか本当に必要なところだけスモールテストをしてヘッダーが表示されているようなのを確認したい画面なのであればそれはミディアムテストとして検証するのが正しいんじゃないかななぜならUIってそういうもんというかUIがあるようなウェブアプリケーションはそういうものだと思うのでなるほど

ピラミッドになるのはバックエンドとかが違いバックエンド以外ないのかなそうかなんかのクーロンみたいなのがあるかもしれないですけどそれもバックエンドっちゃバックエンドですね確かにっていう感じですね

あとすいませんもう一個ページのテストでコンポーネントが呼び出されているかどうかのテストを書くのがBDDっぽくないなぁということもありましたけど僕はBDDなんじゃないかなと思っておりますそれを全部として捉えるとあれだけどそのコンポーネントを使って何かするみたいなところがBDDってことですかそうですねあとはユーザーが気にするところをヘッダー出ててほしいなぁと思ってるならそれはBDDとしてあるべきものうん

ユーザーはトップページでヘッダーの何々を押すことで何ができることっていうユーザーストーリーあるはずなのでそれにのっとってるよねっていうのを検証するのはE2EテストBDDで担保する部分かなと思ったりしてるのではい

BDDって思っていいんじゃないと僕は個人的に思いますE2Eで書くようなテストでもないと思ってますっていうのもありますが1個ぐらい見ていいんじゃないと思いますねなるほどなぜなら

どうなんだろうなまあでも確かにインテグレーションで見れば十分ですねまあ確かに言いついで見る必要はないですね確かにインテグレーションで見ればいいかそのトップページでヘッダーが表示されていることは他のコンポーネント関係ないと思うんで確かにコンポーネントというか他のシステムかアプリ

っていう感じですね確かにわざわざテスト書かなくても言いついテストやった時にぶっ壊れそうだよねなんかどっかのパーツないってなったらそうですねログアウトとか多分ヘッダーからやるでしょうしねはいっていう感じでしたなるほどフロントのテストやったことないなフロントのテストも難しいというか職人技感すごいなと思っててなんかどっからどこまでをユニットでやるとかうん

インテグレーションでどこまで細かく見るとか職人技なんですよねE2Eしかやってないですもんね今?検証だもん他の人のアプリのというかそうですねだから正しいんじゃないそれはそれでE2Eだったら手動じゃないんであの

ヘッダーとかがいろんなページでちゃんと表示されてるかみたいのはループ回すなりで見ても一応いいのかなとは思いますねでもあんまりにも多くなってきて時間かかるようであれば減らした方がいいかなと思うんですけど多分今の僕の現場の思想だとできるならやった方がいいよね邪魔になってきたら減らそうねぐらいの思想でやってるかなと思いますね

CICDのパイプラインとかないんだもんねないというかそういうのじゃないもんねありますテストしたい時にローカルで動かしますしプロリクテストコードとかは書いてるんで上げた時に回るようにしてますしマスターにマージした時とかも

また全部回るようにしてますし毎回ちょっとやってますねそれあれかいやどうしようそんなに深く言えないね仕事の話だからねちょっとやめとこうかな僕も今フロントテスト書いてますけどどんどん開発が進むと機能とか画面が増えていってテスト時間めっちゃ伸びていくんですよそりゃもう

定期的に長すぎるっしょっていうのがレトロスペクティブで上がってきてテスト大改革会議が1回行われたりしてるんですけどそこでめっちゃテストを削ったりユニットテストに回したりとか時間かかるここスナップショット撮んなくてもいいよねみたいなものをスナップショット撮らないで別の検証でいいことにするとかそういう細かーいなんだろう

お掃除すごい求められるちゃんとチューニングしてるいいですねでも時間かかるのよ30分例えばさプルリクでかかるとするじゃん新しい機能作るじゃんよっしゃ多分できたぞプルリクえいってやるじゃないですかでもその時点ではレビュー以来出せないじゃないですか通んないかもしれないし

でテスト落ちるじゃないですか落ちたなーってなるじゃないですか30分待ってでなんかチョロチョロってやって多分これでいけるって言ってもう一回やって通らなかったら1時間ロスするじゃないですかヤバいねヤバいんですよそんぐらいねCIで含み込まれてるテストの長さって罪が深いんで正直Googleの5分ヤバいと思うんですけどプレイライトのテストで5分以内って結構ヤバくない?結構ヤバいですてか多分

無理だと思います多分無理多分無理じゃないいけんのかな分かんないですけどパラレルでやったテストのインスタンスの性能上げればいけますわそういうことか今CPU3つかな4つかながあるインスタンスで試合回してるんですけどCPUの数の分だけはパラレルでいけるんでお金が無限にあれば強くすればいいんでいけますね確かに

でもそんなとこ多分ごく一部だと思うんでインスタンスシビアなとこあるでしょうからそういう工夫が求められる分野ですねちょっとすいません話しすぎました終わります急に大丈夫ですよねU3への回答は満たしてると思いますテストが好きな方がこのポッドキャストを聞いてくれてるのは非常にありがたいですし

みんながもっとテスト好きになればいいなと僕テスト好きなわけじゃないんですけどテストの考え方は好きなんでなんかあのこのTワードさんじゃないですけど仕組みに綺麗に乗っ取っておけばめっちゃ気をつけなくてもある程度は綺麗に書けるというかバグんないみたいな仕組みが徹底してるっていう思想は好きなんでソフトウェアテストの今回お便りいただいてちょっと僕も

勉強になったんで 引き続き何かあったらくださいいやーすごいですね 本当に1年ですかこの方すごいですねわかんないねでも何進数でも1は1ですもんねまあ何進数でも1は1だなじゃあそこに謎解きはないですねじゃあ1かこれで10って送ってきて2の可能性はありますけど確かにな1は1なんだよね1は1だはい はい そうでしたゆうさんお便りありがとうございましたありがとうございますはい じゃあ終わります

ハッシュタグひまじんプログラマーでSNSで癖フィードバック募集してますのでテストに対する疑問とか今日の感想もしくは僕へのまさかりありましたらお願いしますまさかりお願いします本当にそうですよね会長のあとはポッドキャストの説明欄からGoogleフォームで番組のお便り要望感想質問何でもお待ちしてますお願いしますお気楽お

お気軽にお願いします各種ポッドキャストプラットフォームへのフォロー高評価もお待ちしてますのでこちらもお願いいたします最近フォロー増えてきてちょっと嬉しいですね俺もなんかXちらほらフォローしてくれて今までじゅんぺいだけフォローされないという事象が結構多かった本当ですよねフォローしてくれた人見に行ってフォローのとこ見るとのりさんはいるけどじゅんぺいはいない妥当だと思います妥当です

順平もカナダ行くって面白いコンテンツあるからちょっとずれますけどマナさんのポッドキャストの1年間再生数トップエピソード紹介みたいなやつ我々3位入賞させていただきましたけどそこの中で取り上げられてたのはやっぱり順平でしたねそうなんだありがたいありがたいですはいというので終わりますまた次回バイバイやめてー

ラーの爆心流の特殊能力でマスタードブランチが焼き現れたら闇のスパゲティコードと密結合しているじゅんぺうちの心までクラッシュしちゃう死なないでじゅんぺうちあんたがここでクラッシュしたら先方との契約はどうなっちゃうのソースコードはまだ修正の位置があるここを耐えればもう納品できるんだから次回納期おにおうずスタンバイ