テストコードの意味がない
個人開発のバイブコーディングでテストコードを書かせているが意味がなかった。
期待する機能をプロンプトで指示しプロダクションコードが出来上がるが、同時にテストコードも書かせていた。
そのテストコードは、プロダクションコードをそのままテストコードとして書き落としただけの写経コードだ。
テストが通る架空の安心感だけ得られるが、それは虚無。
つい先日、リファクタリングを行った。
静的解析のルールを追加した関係で、それをクリアするようにプロダクションコードが修正させた。
すると、プロダクションコードの大幅な変更に伴いテストコードも同時に修正された。
問題は、プロダクションコードの内容をそのままテストコードが反映させているため、
期待する機能仕様が満たせていないにも関わらずテストが成功してしまった。
これはテストではなく、ただファイル作成しているだけだ。
仕様 is どこ
現時点だと、プロダクションコードの挙動が仕様となり、それを満たすためにテストコードが生まれている。
それはよろしくなく、先の問題が発生してしまう。
プロダクションコードではなく、別の言語で仕様を定義する必要がある。
テストレイヤーなどの話をしたい訳ではなく、ただ仕様を壊さないようにしたいだけだ。
古き良きスタイルだと、エクセルやワードで仕様書を定義するのかもしれないが重たい。
今だと、宣言的ファイルやマークダウンファイルなどのプレーンファイルだと扱いやすく、様々なエコシステムとの相性が良い。
そのようなファイル群に "仕様" を言語化し、"仕様" を満たすテストコードがあって欲しい。
その解決策の1つとして、Gherkin が使えるのではと思いつつある。
Gherkin の良い点は、自然言語で システムの振る舞いを言語化することができ、かつそれをテストコードとして扱うことができる点だ。
面倒だけどやらねば
仕様を書くのは面倒だ。
ただ、仕様を壊す変更に気づけないのはもっと面倒だ。
なので、個人開発でも最低限守りたい部分を言語化させている。
とはいえ全部0から書く訳ではなく、文章の叩き台を自分が作って、後は AI に助けてもらう。
文章の精査ができたら、テストコードは任せるが「テストが通るための修正」みたいなことをされると結局意味がないので、
そこの部分はレビューを疎かにしないでいこう。
※ 今まであった テストファイルは消しちゃおう。（単なる写経コードだ）
-
※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
関連する記事
タグ「AI」の記事
以下で書いた通り、プロダクトコードを写経したテストコードを削除しました。 "こぶりー" ( https://kobliy.vercel.app/ ) という個人ブログを読むアプリのコードです。 https://silverbirder.gi
最近のお悩みは、Webのソフトウェア開発におけるテストコードが爆増したことにより、 テスト成功による過度な安心感 によって手動確認するのが減っているのかもと思ったりしています。 例えば、Webのフォーム画面に小さな改修があったとして、その修
今朝、長らくお世話になった GitHub Copilot を解約し、 OpenAI Codex を Plus から Pro にアップグレードしました。 経緯 今月、5月4日あたりから OpenAI Codex で何度か上限制限（5時間以内）
2026年05月09日
タグ「テスト」の記事
以下で書いた通り、プロダクトコードを写経したテストコードを削除しました。 "こぶりー" ( https://kobliy.vercel.app/ ) という個人ブログを読むアプリのコードです。 https://silverbirder.gi
業務でWebフロントエンドのテストコードを書く際に、どこに何を書くかというのをざっくりと考えをまとめてみます。 前提 Webアプリケーションのプログラムファイルがツリー構造である前提とします。 tree よくあるフィーチャー単位のフォルダ構
2026年06月05日
最近、Testcontainers を使う機会があり、苦労したことについて備忘録として残しておきます。 前提 以下の記事で書いてある構成に近いものです。 https://zenn.dev/silverbirder/articles/0a54
2026年05月14日