念の為に、手動確認をしよう
最近のお悩みは、Webのソフトウェア開発におけるテストコードが爆増したことにより、
テスト成功による過度な安心感 によって手動確認するのが減っているのかもと思ったりしています。
例えば、Webのフォーム画面に小さな改修があったとして、その修正後の動作確認です。
フォーム画面でよくあるのは、フォーム入力の検査やフォーム入力を外部へ送信する処理などがあります。
検査のロジックを修正する場合、イマドキの開発スタイルだと検査ロジックをモジュールごと切り出して、
そこのプロダクションコードのロジックとテストコードがセットになっていて、そのテストコードで検査ロジックを検証します。
- 「検査ロジックだけ直したのだから、そこのテストコードが成功したらOKでしょ」
- 「他のテストコードも成功してるんだから、だいじょぶだいじょぶ」
と思っちゃうかもしれませんが、Webアプリケーションは単体モジュールの組み合わせによって成り立っているのが多いので、
部分的なチェック（全体の1部分だけ）というのは少々不安なんです。
バグがないプロダクションコードがないこと同様に、テストコードも完璧に仕様を守れているとは限りません。
なので、クライアント部分（Webの場合はブラウザ）で修正箇所を一度手動確認する、というのが私のポリシーかもしれません。
- 「フォームの検査ロジックを変えたら、送信時にサーバからエラーが返ってきた」
のように、全体を見ると「あれ？」と気づく可能性があります。
人間は完璧に実装できていないと思い、手動確認しつつ、確認作業を楽にするためのテストコード、のニュアンスが良いなと思います。
（テストコードの良いところは、打鍵削減、仕様明確、品質保証の3つ）
もちろん、その一連の操作もテストシナリオとして組み込めばより安全になるのかもしれませんが、
"人間の目でチェックして気づくこと" は仕組み化するのは難しい ので手動確認する、というのが個人的見解です。
モンキーテストライブラリを入れても良いですが、あれは一種のカオステストなだけで、今回の例を気づけるかと言われると疑問です。
じゃあどこまでやれば良いのか？と言われると、自分の中ではケースバイケースなので言語化が難しいかもです。
とりあえず、正常系や準異常系ぐらいは見るかもしれません。
あとは、データ依存や時間依存、時系列や権限ロール、環境などケースバイケースで確認するポイントは様々と思います。（ふわっと）
-
s※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
関連する記事
タグ「AI」の記事
OpenAI の Codex を普段から愛用しています。 開発において、VS Code や IntelliJ IDEA という枯れたメジャーエディタを使っていましたが、 最近は Codex Desktop App だけでも案外イケるかも？と
ITヲタクな AI くんにピッタリな仕事の一つは、モジュールアップデート。 特に、メジャーアップデートが超助かる。 昔だったら 数ヶ月掛かった移行も、数日たらずに対応できるようになったので、 さすが ITヲタクくん。 対応してよかったフロー
この記事をかくときは、100%人の手で書いています。 UIをつくるときも、100%人の手で書いています。 （ロジックは AI に書かせます） 他にはプレゼンテーションやスライドといった書き物も、 コンテンツ準備は AI にさせますが、文章を
タグ「フロントエンド」の記事
Webmention というのを最近知りました。 名前の通り、Web 上でメンションすることができます。 受信側、送信側、どちらも対応したので感想を残そうと思います。 Webmention ざっくりと Web AサイトにBサイトのリンクをつ
ITヲタクな AI くんにピッタリな仕事の一つは、モジュールアップデート。 特に、メジャーアップデートが超助かる。 昔だったら 数ヶ月掛かった移行も、数日たらずに対応できるようになったので、 さすが ITヲタクくん。 対応してよかったフロー
以下で書いた通り、プロダクトコードを写経したテストコードを削除しました。 "こぶりー" ( https://kobliy.vercel.app/ ) という個人ブログを読むアプリのコードです。 https://silverbirder.gi