自分の発信を1か所に集めるハブサイト「Hubpin」を、個人で作りました。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
Claude Code を取り入れながら、設計から実装まで一人で進めています。
外部のフィードを1日1回取りに行く処理に、テストを足していました。
固定したかったのは、たった1行の判断です。
取得結果が0件だったとき、保存処理を呼ばない。
なぜここを守りたかったのかを書いておきます。
その1行を消すと、全部の計器が緑のままでした
判定を外すとどうなるかを確かめました。
ログのテーブルには成功と記録されます。
通信の応答も正常を返します。
管理画面から見ても、異常はありません。
壊れているのは、ログインしていない人が見る公開ページだけでした。
そこが空になります。
自分がログインした状態で見ているかぎり、気づけない形でした。
しかも、待っても直りません
もう少し悪い性質がありました。
0件で既存のデータを上書きしたあと、ページのキャッシュがそのまま焼き直されます。
空の状態で固定されることになります。
次に取りに行くのは24時間後です。
その日のうちに直ることはありません。
気づくまでの時間は、取得の間隔では決まりませんでした。
誰かが公開ページを見るまでです。
何分で気づけるかと聞かれて、外しました
この挙動は、テストを書いたあとに聞かれる形で出てきました。
この判定を外したら、何分で気づけますか。
自分の答えは60分でした。
取得は1日1回なので、時間の見積もりとしては大きく外しています。
ただ、キャッシュが関係しているのではないか、という筋は当たっていました。
実際に、空のまま焼き直される部分が効いています。
同じ日の夜、網羅的に測ったら10箇所ありました
ここまでは、テストを書いている最中に1箇所見つけた話です。
その日の夜、全体レビューの中で網羅的に測ってもらいました。
リポジトリを作業用の場所に複製して、実装をわざと10箇所壊して、テストを走らせています。
10箇所すべてで、52本のテストが緑のままでした。
いちばん堪えたもの
10箇所のうち、ひとつが特に効きました。
並び替えの「上へ移動」の処理に、逆方向の値を渡しても緑でした。
並び替えが壊れないことは、このアプリで必ず守ると決めた3つのうちの1つです。
それを守るために書いたはずのテストが、壊れたことに気づけていませんでした。
本数は書けても、守備範囲は書けません
テストが52本ある、というのは説明書きに書けます。
52本が何を守っているかは、書けませんでした。
10箇所壊して全部緑だった時点で、本数と守備範囲は別のものだとはっきりしました。
監視やログを足すのも同じだと思っています。
足した先が、見ているつもりの場所だったら意味がありません。
成功か失敗かの二択では足りませんでした。
成功したけれど中身が0件、という3つ目の状態があります。
