テストコードの意味がない
個人開発のバイブコーディングでテストコードを書かせているが意味がなかった。
期待する機能をプロンプトで指示しプロダクションコードが出来上がるが、同時にテストコードも書かせていた。
そのテストコードは、プロダクションコードをそのままテストコードとして書き落としただけの写経コードだ。
テストが通る架空の安心感だけ得られるが、それは虚無。
つい先日、リファクタリングを行った。
静的解析のルールを追加した関係で、それをクリアするようにプロダクションコードが修正させた。
すると、プロダクションコードの大幅な変更に伴いテストコードも同時に修正された。
問題は、プロダクションコードの内容をそのままテストコードが反映させているため、
期待する機能仕様が満たせていないにも関わらずテストが成功してしまった。
これはテストではなく、ただファイル作成しているだけだ。
仕様 is どこ
現時点だと、プロダクションコードの挙動が仕様となり、それを満たすためにテストコードが生まれている。
それはよろしくなく、先の問題が発生してしまう。
プロダクションコードではなく、別の言語で仕様を定義する必要がある。
テストレイヤーなどの話をしたい訳ではなく、ただ仕様を壊さないようにしたいだけだ。
古き良きスタイルだと、エクセルやワードで仕様書を定義するのかもしれないが重たい。
今だと、宣言的ファイルやマークダウンファイルなどのプレーンファイルだと扱いやすく、様々なエコシステムとの相性が良い。
そのようなファイル群に "仕様" を言語化し、"仕様" を満たすテストコードがあって欲しい。
その解決策の1つとして、Gherkin が使えるのではと思いつつある。
Gherkin の良い点は、自然言語で システムの振る舞いを言語化することができ、かつそれをテストコードとして扱うことができる点だ。
面倒だけどやらねば
仕様を書くのは面倒だ。
ただ、仕様を壊す変更に気づけないのはもっと面倒だ。
なので、個人開発でも最低限守りたい部分を言語化させている。
とはいえ全部0から書く訳ではなく、文章の叩き台を自分が作って、後は AI に助けてもらう。
文章の精査ができたら、テストコードは任せるが「テストが通るための修正」みたいなことをされると結局意味がないので、
そこの部分はレビューを疎かにしないでいこう。
※ 今まであった テストファイルは消しちゃおう。（単なる写経コードだ）
-
s※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
関連する記事
タグ「AI」の記事
AI 並列作業していると、状況教えてと何度も聞いちゃいます。 覚えれない それぞれの作業がどのような内容かなんとなくは覚えていますが、 並列で作業させると基本的に忘却します。 そうすると「状況教えて」と聞いて進捗を教えてもらいます。 その後
Codex や Claude のデスクトップアプリにあるピン留め機能が気に入っています。 ピン留めというメタファ 髪の毛を束にしてまとめるためのピン留めや、 コルクボードに紙を止めるためのピン留めなど、 何かを固定するというメタファがピン留
OpenAI の Codex を普段から愛用しています。 開発において、VS Code や IntelliJ IDEA という枯れたメジャーエディタを使っていましたが、 最近は Codex Desktop App だけでも案外イケるかも？と
タグ「テスト」の記事
個人開発（趣味）レベルですが、テストに対するスタンスについて簡単に書きます。 コードレビュー 物量に圧倒されるプロダクションコードとテストコードをレビューするのは、 書く工程が減ったため読む深みが浅くなっています。 DIPやインターフェース
2026年10月03日
Testcontainers + Playwright + Cucumber.js による受け入れテストを、公私ともに活用しています。 運用していて気づいた点について、また書き残そうと思います。 開発PR単位でE2Eテスト これはTestc
2026年09月07日
テストコードをテストする、ミューテーションテスト。 プロダクションコードを突然変異でコードを書き換えたら（ミューテーション）、テストが失敗してくれるかどうか。 失敗するということは、不具合を検知できたということです。 ミューテーションする箇
2026年08月25日