念の為に、手動確認をしよう
最近のお悩みは、Webのソフトウェア開発におけるテストコードが爆増したことにより、
テスト成功による過度な安心感 によって手動確認するのが減っているのかもと思ったりしています。
例えば、Webのフォーム画面に小さな改修があったとして、その修正後の動作確認です。
フォーム画面でよくあるのは、フォーム入力の検査やフォーム入力を外部へ送信する処理などがあります。
検査のロジックを修正する場合、イマドキの開発スタイルだと検査ロジックをモジュールごと切り出して、
そこのプロダクションコードのロジックとテストコードがセットになっていて、そのテストコードで検査ロジックを検証します。
- 「検査ロジックだけ直したのだから、そこのテストコードが成功したらOKでしょ」
- 「他のテストコードも成功してるんだから、だいじょぶだいじょぶ」
と思っちゃうかもしれませんが、Webアプリケーションは単体モジュールの組み合わせによって成り立っているのが多いので、
部分的なチェック（全体の1部分だけ）というのは少々不安なんです。
バグがないプロダクションコードがないこと同様に、テストコードも完璧に仕様を守れているとは限りません。
なので、クライアント部分（Webの場合はブラウザ）で修正箇所を一度手動確認する、というのが私のポリシーかもしれません。
- 「フォームの検査ロジックを変えたら、送信時にサーバからエラーが返ってきた」
のように、全体を見ると「あれ？」と気づく可能性があります。
人間は完璧に実装できていないと思い、手動確認しつつ、確認作業を楽にするためのテストコード、のニュアンスが良いなと思います。
（テストコードの良いところは、打鍵削減、仕様明確、品質保証の3つ）
もちろん、その一連の操作もテストシナリオとして組み込めばより安全になるのかもしれませんが、
"人間の目でチェックして気づくこと" は仕組み化するのは難しい ので手動確認する、というのが個人的見解です。
モンキーテストライブラリを入れても良いですが、あれは一種のカオステストなだけで、今回の例を気づけるかと言われると疑問です。
じゃあどこまでやれば良いのか？と言われると、自分の中ではケースバイケースなので言語化が難しいかもです。
とりあえず、正常系や準異常系ぐらいは見るかもしれません。
あとは、データ依存や時間依存、時系列や権限ロール、環境などケースバイケースで確認するポイントは様々と思います。（ふわっと）
-
※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
関連する記事
タグ「AI」の記事
個人開発のバイブコーディングでテストコードを書かせているが意味がなかった。 期待する機能をプロンプトで指示しプロダクションコードが出来上がるが、同時にテストコードも書かせていた。 そのテストコードは、プロダクションコードをそのままテストコー
今朝、長らくお世話になった GitHub Copilot を解約し、 OpenAI Codex を Plus から Pro にアップグレードしました。 経緯 今月、5月4日あたりから OpenAI Codex で何度か上限制限（5時間以内）
2026年05月09日
AI で生成された低品質なもの、AI Slop と呼ばれます。 呼び名はなんでも良いですが、この種のコンテンツを目にするたびに落胆します。 ネット記事や、プルリクエストの説明文、議題とディスカッション、あらゆるところに登場します。 めっちゃ
タグ「フロントエンド」の記事
以下で書いた個人ブログを読むアプリ（個人ブログライブラリ、略して "こぶりー" ）をモバイルアプリで開発していました。 https://silverbirder.github.io/blog/contents/20260419/ 審査関連で
2026年05月11日
過去にモバイルアプリを作ろうとして断念したことがありました。 https://silverbirder.github.io/blog/contents/first-mobile-app-failure/ 最近、作りたいモバイルアプリのネタが
2026年04月14日
また、以下の記事の続きを書こうと思います。 https://silverbirder.github.io/blog/contents/20260312/ ビジネスロジック アプリケーションのビジネスロジックに関することについて書きます。 複
2026年03月18日