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