自分の発信を1か所に集めるハブサイト「Hubpin」を、個人で作りました。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
Claude Code を取り入れながら、設計から実装まで一人で進めています。
外部から記事を取ってくる処理に、テストを書いていました。
手順書はAIに書いてもらっています。
その中に、完了条件がひとつ入っていました。
書いたテストがちゃんと機能しているか、実装をわざと壊して赤くなるか見る。
テストが通ることだけを見ていると、何も確かめていないテストが緑のまま残ります。
それを防ぐための手順です。
赤くなったので、通しかけました
判定を1行消して実行したら、ちゃんと赤くなりました。
これで確認できた、と思ったところで、出力を読んでみました。
期待していたのと違うメッセージが出ています。
Expected: "Zenn の RSS が"
Received: res.text is not a function判定を消すと、処理はその先へ進みます。
その先で必要になるものを、テスト側で用意していませんでした。
つまり、判定が無いと素通りすることを確かめたのではなく、別の理由で落ちていただけでした。
用意し直したら、違うメッセージが出ました
足りないものを用意してから、もう一度同じ場所を壊しました。
今度はこう出ました。
promise resolved "[]" instead of rejectingこれが出て、初めて検証になっています。
目的そのものを、確かめる側が踏んでいました
この工程で守りたかったのは、取得に失敗したのに0件として扱われて通ってしまうことでした。
2回目に出た空の配列は、まさにその形です。
防ぎたかった失敗と同じことを、それを確かめるための手順自身がやっていました。
完了条件の書き方を変えました
直したのは実装ではなく、手順書のほうです。
わざと壊して落ちることを1回見る、という書き方をやめました。
どのメッセージで落ちるかまで見る、に変えています。
赤くなったこと自体は、空振りのときも同じでした。
区別できるのは理由だけです。
同じ手順が他に2箇所あったので、そちらにも同じ行を足しました。
通したい方向に結果が出ると、緩みます
一番持ち帰ったのはここでした。
失敗するはずのものが失敗したとき、理由を読まずに次へ進みそうになります。
期待どおりの結果が出ているので、疑う理由がありません。
テストに限らず、入力チェックを外して弾かれるか見るときも、権限を落として弾かれるか見るときも、同じことが起きると思います。
