環境リセットや日時モックの整備が本番コード書くより遥かに面倒なんだよな。本質突きすぎてて耳が痛い
おもろすぎる。AIの時代にまったく合わないので、誰も教えないうちに誰にも必要でなくなっちゃってる。
本当の壁はやる気でなく、テスト用データや時刻固定など前提整備の価値が見えにくく優先度が落ち続ける構造。まず全画面の200と404確認から積み、段階を踏むのが現実的だ
準備が大変。
AIが勝手に
うわやめろなにをす
“テストコードを書くこと自体は、実は話の半分以下だ。テストが動く前提を整えることが、テスト自動化の本当のコスト。一番デカいのがテスト用のデータの準備。さらに厄介なのが時間依存のデータだ”
テスト作り続けているうちに、この時間で実装進めた方が効率的なんじゃ…って気持ちがどんどん強くなって来ちゃうんだよね
モックはやめろとは聞く
AIはちゃんとテスト書いてくれるよね。
AIの時代だからこそ必要になってきそう。
内容ではないよう。既存の検証プロセスを再構築するコスト対価が取れないんでしょ。だから逆に新規プロジェクトは結構入ってるイメージよ。
自分がここ数年で関わった案件はテスト自動化したいけど人もいないし時間もない状態がほとんどだったなあ。テスト頑張ろうとしてたところはデータの問題に苦しんでたし、この記事わかりみありすぎる。
なかなかね。スポンサーとかからのトップダウンで進めるぞってなっても、笛吹けど踊らずになりますよね
そうよ 締め切りがあるのよね テストは最終工程だし削れないし増やせないし コンセンサスを取るのも大変なのよ🍷
テストデータや環境整備にコストがかかし難易度も高いから、か。そして、簡単なことから始めたらいいという提案をしている。ユーティリティの単体テストくらいは書くから、E2Eテストのことを言っているんだろうね。
同意しすぎて首がもげるやつだ(´・ω・`) 何が何でも完璧な品質保証を目指すんではなくて、自動化することで何を担保したいのか、目的意識を持って活用したいですよね(´・ω・`)
勘所を付かんで抽象化しているだけでモックとかテストは結構簡単に導入できる。問題はスタートアップやフレームワークがそこまで細かく対応していないので、アプリ規模が大きくなってから導入しようとして泣く。
自動テスト書いた経験なさそう
「テストを実行するためには、テスト用のデータが必要だ。」まさに。これについて書いてる記事は皆無だった気がする
TDDの基本として最初にテストを設計してシステムに組み込んでおかないと無理です。そのためには、これから作るシステムを完璧に理解しているアーキテクトが必要。後は分かるね？
テストコードを書くコスト→AIにソースコード見て作らせたら必ずテストが通るコードをなるので仕様書セットになるが、今度は仕様書をAIがわかるようにきちんと書くためのコスト…あれ、これは必要なコストだな？🫤
E2E の話だな。ユニットテストには当てはまらない。
作って収めるだけの受託開発ではコスト回収できない。動くものを早く出す必要もあるし。逆にエンハンスが継続的に計画されてるなら見積もりに入れてしっかりやってる。エージェント開発では必須になる。
テストを自動化してない現場をここ15年ぐらいほぼみたことがなくて、こういう世界もあるんだなという驚きと、自分の幸運への感謝がある
“コード化して確認できるテストは書けばいい。ただ、そこで悩まないといけないくらいなら、アナログなモンキーテストでいいって割り切って見てもいいと思う。”
どこの世界の話？SIerであれば自動テストを書くか否かは契約で決まっているので個人の自由と関係ない。
“テストコードを書くためには、三つのことを同時に高い水準で理解していないといけない”/xUnitとTDDの話が混ざってそうな気がしてる
テストの基本はユニットテスト。これわかってない人今すぐプログラマやめろ。十分に洗練されたユニットテストがあればE2Eテストはいらないといっても過言ではない。根本的におかしいことを言ってることに気づいてくれ
今時だと「クラウドサービスのAPIを呼び出す組み込み機器の液晶画面で動くGUIアプリ」みたいなのもあってモック化にも限界あるわってなるのよね。
全部E2Eで用意しようとするから…
一昔前の話ならわかるが…
自分の観測範囲では普通に普及してるんだけど、普及してないんじゃなくてただ単にアクセンチュアがクソなだけなのでは
「オレの設計とコードは完璧で、絶対にバグは出さないし、仮に出たとしてもちょっと見ればソッコー治せるし」おじさんのせいです
テストが普及しない職場って『コード修正＝ドメインロジックの変更』の図式が強く成り立ってるとこな気がする。テストはそのまま実装コードだけ修正みたいな機会が少ないと自動テストの旨みも小さい。
E2Eせずに、出来る限りユニットテストで機能保障したいが、とはいえDB関連やホスト通信、外部API等、外部とのあらゆるインターフェースが想定通りに実装されているというのは油断。なのでE2Eはやろうね。
期待値が正しいか判断するためのドメイン知識が必須な話がないのはさみしいなぁ
てかテスト書いてないコードがレビュー通るわけないし、PRで弾かれて終わりだ。令和何年だと思ってる？日付が10年前ってわけでもなさそう。
これ、「普及しない理由」が説明されていない気がする。本文にひと言も「普及」って単語が無いし、『本質的に難しいから』なんて分かりきったこと。あと、対話調が読んでいてキッツい…。シンプルに書いてほしい
開発者の心境に寄り添ってくれる良い記事だった。今時は生成AIがテスト書いてくれるが、少しでも油断するとassert(1+1, 2)みたいなのを書いて自画自賛してるから辛さはあまり変わってない。早く生成AIもっと進化しろ。
結局、テストにリソース投下できるかは「経験と組織」の問題。事故経験があれば事故処理コストと比較できるし、内製ならリソース確保もしやすい。運用経験のない、作って終わりの受託開発なら一生やらないだろうね
アクセンチュアなんて受託開発して下請けに投げるのが仕事なんだからテストコードなんて書かないだろうし、下請けだってそんな見積もり出せないでしょ。自動テストやるなら自社サービスとかじゃないと厳しいて
いろいろなところの会社と関わりを持っているけど、ここ10年でだいぶ変わったという印象があるし、業界を絞れば普及は当たり前にしている。 そしてテストに関する本もここ10年でだいぶ増えたよ。
「うちは出来てる」っていう人、ここに上がってる課題のクリアの仕方を書いてくれ。多分そもそもそんな試験しないか、起点から違うんだろうけど。個別DBの話、締めじゃないと起きない話、客がウンコな話。
テストが書けないという事は、副作用や関心事を分離した設計が出来ないのと同義。社名を出してレベルの低い話をさも一般的な話かのように語るのは止めたほうがいいと思う。
テスト書く前にリファクタリングでしょっていうプロダクトを保守している人はどうすればいいですか。
要するに設計と工数の問題なんだけど...
テスト自動化しない界隈があんのか。こわ、治安わる…。AIがあるんだから、Gherkinで仕様定義してAIに書かせろよ。てか実装もさせとけ。
テスト自動化を組織に根付かせるのは本当に大変だよ。いくらテスト書いても「手でテストするの良いですよ！」とかナチュラルにテスト無しコードが増殖してバグが減らないからな。
ウチは出来てないけど、間違いなくリソースですね。それ以外ってあります？／あと、ブラックボックステストは厳しいけどホワイトボックステストってそんなに難易度高いですかね。単に端折られてるだけな気が。
大前提としてテストコードと環境はシステムと一蓮托生で、生まれた瞬間から決まっている許婚くらいのポジションなので、1995年生まれの30歳独身10万行ソースコードに自動テストなんて今更無理なんですね
でかすぎる豆腐が自重に耐えられずに崩壊するように、基本ができてないソフトはやがて崩壊する。そこを経営者が理解してまともな予算を付けられるかどうかがまず壁。
技術的な話を会話調や小説調で書かないでほしい。
テストが書けないコードだから、では。肥大化したController、抽象化されてないデータアクセスに外部API呼び出し。モックの注入すら困難なコードたちで、御社のビジネスを加速する最適なソリューションを。
テストは最初に単体・結合両方を用意しておいて維持しながら開発するのが一番コストが安い。テストが維持できなくなるのはテストし難いコードを書くからだ。テストしやすいコード・環境は最初なら簡単に作れる。
SIerは工数商売なので合理化・効率化する動機がないだけ
いいからとにかく書くんだ！書いて、それから学べ！
テストソース作るから金と時間くれって言ってもはいって言わない顧客が悪い。そのくせCI/CDを構築したらリリース頻度上げられるんでしょ？とか言ってきやがる
"俺が自動テストを書けない理由" と "皆が自動テストを書いてくれない理由" がごっちゃになってる様な(勿論被ってる部分はあるが).「普及しない理由」は後者に焦点を当てるべきでは
誰も教えてくれないテスト自動化が普及しない理由
環境リセットや日時モックの整備が本番コード書くより遥かに面倒なんだよな。本質突きすぎてて耳が痛い
おもろすぎる。AIの時代にまったく合わないので、誰も教えないうちに誰にも必要でなくなっちゃってる。
本当の壁はやる気でなく、テスト用データや時刻固定など前提整備の価値が見えにくく優先度が落ち続ける構造。まず全画面の200と404確認から積み、段階を踏むのが現実的だ
準備が大変。
AIが勝手に
うわやめろなにをす
“テストコードを書くこと自体は、実は話の半分以下だ。テストが動く前提を整えることが、テスト自動化の本当のコスト。一番デカいのがテスト用のデータの準備。さらに厄介なのが時間依存のデータだ”
テスト作り続けているうちに、この時間で実装進めた方が効率的なんじゃ…って気持ちがどんどん強くなって来ちゃうんだよね
モックはやめろとは聞く
AIはちゃんとテスト書いてくれるよね。
AIの時代だからこそ必要になってきそう。
内容ではないよう。既存の検証プロセスを再構築するコスト対価が取れないんでしょ。だから逆に新規プロジェクトは結構入ってるイメージよ。
自分がここ数年で関わった案件はテスト自動化したいけど人もいないし時間もない状態がほとんどだったなあ。テスト頑張ろうとしてたところはデータの問題に苦しんでたし、この記事わかりみありすぎる。
なかなかね。スポンサーとかからのトップダウンで進めるぞってなっても、笛吹けど踊らずになりますよね
そうよ 締め切りがあるのよね テストは最終工程だし削れないし増やせないし コンセンサスを取るのも大変なのよ🍷
テストデータや環境整備にコストがかかし難易度も高いから、か。そして、簡単なことから始めたらいいという提案をしている。ユーティリティの単体テストくらいは書くから、E2Eテストのことを言っているんだろうね。
同意しすぎて首がもげるやつだ(´・ω・`) 何が何でも完璧な品質保証を目指すんではなくて、自動化することで何を担保したいのか、目的意識を持って活用したいですよね(´・ω・`)
勘所を付かんで抽象化しているだけでモックとかテストは結構簡単に導入できる。問題はスタートアップやフレームワークがそこまで細かく対応していないので、アプリ規模が大きくなってから導入しようとして泣く。
自動テスト書いた経験なさそう
「テストを実行するためには、テスト用のデータが必要だ。」まさに。これについて書いてる記事は皆無だった気がする
TDDの基本として最初にテストを設計してシステムに組み込んでおかないと無理です。そのためには、これから作るシステムを完璧に理解しているアーキテクトが必要。後は分かるね？
テストコードを書くコスト→AIにソースコード見て作らせたら必ずテストが通るコードをなるので仕様書セットになるが、今度は仕様書をAIがわかるようにきちんと書くためのコスト…あれ、これは必要なコストだな？🫤
E2E の話だな。ユニットテストには当てはまらない。
作って収めるだけの受託開発ではコスト回収できない。動くものを早く出す必要もあるし。逆にエンハンスが継続的に計画されてるなら見積もりに入れてしっかりやってる。エージェント開発では必須になる。
テストを自動化してない現場をここ15年ぐらいほぼみたことがなくて、こういう世界もあるんだなという驚きと、自分の幸運への感謝がある
“コード化して確認できるテストは書けばいい。ただ、そこで悩まないといけないくらいなら、アナログなモンキーテストでいいって割り切って見てもいいと思う。”
どこの世界の話？SIerであれば自動テストを書くか否かは契約で決まっているので個人の自由と関係ない。
“テストコードを書くためには、三つのことを同時に高い水準で理解していないといけない”/xUnitとTDDの話が混ざってそうな気がしてる
テストの基本はユニットテスト。これわかってない人今すぐプログラマやめろ。十分に洗練されたユニットテストがあればE2Eテストはいらないといっても過言ではない。根本的におかしいことを言ってることに気づいてくれ
今時だと「クラウドサービスのAPIを呼び出す組み込み機器の液晶画面で動くGUIアプリ」みたいなのもあってモック化にも限界あるわってなるのよね。
全部E2Eで用意しようとするから…
一昔前の話ならわかるが…
自分の観測範囲では普通に普及してるんだけど、普及してないんじゃなくてただ単にアクセンチュアがクソなだけなのでは
「オレの設計とコードは完璧で、絶対にバグは出さないし、仮に出たとしてもちょっと見ればソッコー治せるし」おじさんのせいです
テストが普及しない職場って『コード修正＝ドメインロジックの変更』の図式が強く成り立ってるとこな気がする。テストはそのまま実装コードだけ修正みたいな機会が少ないと自動テストの旨みも小さい。
E2Eせずに、出来る限りユニットテストで機能保障したいが、とはいえDB関連やホスト通信、外部API等、外部とのあらゆるインターフェースが想定通りに実装されているというのは油断。なのでE2Eはやろうね。
期待値が正しいか判断するためのドメイン知識が必須な話がないのはさみしいなぁ
てかテスト書いてないコードがレビュー通るわけないし、PRで弾かれて終わりだ。令和何年だと思ってる？日付が10年前ってわけでもなさそう。
これ、「普及しない理由」が説明されていない気がする。本文にひと言も「普及」って単語が無いし、『本質的に難しいから』なんて分かりきったこと。あと、対話調が読んでいてキッツい…。シンプルに書いてほしい
開発者の心境に寄り添ってくれる良い記事だった。今時は生成AIがテスト書いてくれるが、少しでも油断するとassert(1+1, 2)みたいなのを書いて自画自賛してるから辛さはあまり変わってない。早く生成AIもっと進化しろ。
結局、テストにリソース投下できるかは「経験と組織」の問題。事故経験があれば事故処理コストと比較できるし、内製ならリソース確保もしやすい。運用経験のない、作って終わりの受託開発なら一生やらないだろうね
アクセンチュアなんて受託開発して下請けに投げるのが仕事なんだからテストコードなんて書かないだろうし、下請けだってそんな見積もり出せないでしょ。自動テストやるなら自社サービスとかじゃないと厳しいて
いろいろなところの会社と関わりを持っているけど、ここ10年でだいぶ変わったという印象があるし、業界を絞れば普及は当たり前にしている。 そしてテストに関する本もここ10年でだいぶ増えたよ。
「うちは出来てる」っていう人、ここに上がってる課題のクリアの仕方を書いてくれ。多分そもそもそんな試験しないか、起点から違うんだろうけど。個別DBの話、締めじゃないと起きない話、客がウンコな話。
テストが書けないという事は、副作用や関心事を分離した設計が出来ないのと同義。社名を出してレベルの低い話をさも一般的な話かのように語るのは止めたほうがいいと思う。
テスト書く前にリファクタリングでしょっていうプロダクトを保守している人はどうすればいいですか。
要するに設計と工数の問題なんだけど...
テスト自動化しない界隈があんのか。こわ、治安わる…。AIがあるんだから、Gherkinで仕様定義してAIに書かせろよ。てか実装もさせとけ。
テスト自動化を組織に根付かせるのは本当に大変だよ。いくらテスト書いても「手でテストするの良いですよ！」とかナチュラルにテスト無しコードが増殖してバグが減らないからな。
ウチは出来てないけど、間違いなくリソースですね。それ以外ってあります？／あと、ブラックボックステストは厳しいけどホワイトボックステストってそんなに難易度高いですかね。単に端折られてるだけな気が。
大前提としてテストコードと環境はシステムと一蓮托生で、生まれた瞬間から決まっている許婚くらいのポジションなので、1995年生まれの30歳独身10万行ソースコードに自動テストなんて今更無理なんですね
でかすぎる豆腐が自重に耐えられずに崩壊するように、基本ができてないソフトはやがて崩壊する。そこを経営者が理解してまともな予算を付けられるかどうかがまず壁。
技術的な話を会話調や小説調で書かないでほしい。
テストが書けないコードだから、では。肥大化したController、抽象化されてないデータアクセスに外部API呼び出し。モックの注入すら困難なコードたちで、御社のビジネスを加速する最適なソリューションを。
テストは最初に単体・結合両方を用意しておいて維持しながら開発するのが一番コストが安い。テストが維持できなくなるのはテストし難いコードを書くからだ。テストしやすいコード・環境は最初なら簡単に作れる。
SIerは工数商売なので合理化・効率化する動機がないだけ
いいからとにかく書くんだ！書いて、それから学べ！
テストソース作るから金と時間くれって言ってもはいって言わない顧客が悪い。そのくせCI/CDを構築したらリリース頻度上げられるんでしょ？とか言ってきやがる
"俺が自動テストを書けない理由" と "皆が自動テストを書いてくれない理由" がごっちゃになってる様な(勿論被ってる部分はあるが).「普及しない理由」は後者に焦点を当てるべきでは