あ
あかね
テストは生きたドキュメントである
2026年03月16日
Tips
要約を生成中...
最近バックエンドを書いていて、テストがないと不安になる瞬間や、このテストケースは書いてテストで実装の担保をしないとって思う場面が増えてきました。
フロントエンドばっかり書いていたときやテストの経験が浅い頃は、正直そこまで強く感じたことはありませんでした。
もちろんテストがある方がいいのは分かっています。
でも、フロントエンドに関しては
UIを触れば確認できる
ブラウザで挙動を見れば分かる
ローカルで試せる
という安心感があります。
でもバックエンドではこの感覚とは少し違うなと思いました。
フロントエンドのコードは、結果が画面に出ます。
例えば、
レイアウト崩れる
ボタン押せない
データ表示されない
こういう問題はちょっと挙動の確認したらすぐ気づきます。
でもAPIは違います。
APIの処理は大体以下のような内容です。
データベース検索
join
集計
フィルタ
ビジネスロジック
フロントに返る結果はJSONだけですよね。。
API側のバグでフロントが壊れた時に、どっちの問題なのかはテストがないとわかりません。
バックエンドを書いていると、1行の変更で結果が変わることがあります。
例えば
クエリの書き方
集計方法
絞り込み条件
テーブルへのカラムの追加
こういった変更です。
しかも、エラーは出ないしAPIは普通に返るんですよね、、、でも件数が少し違うとか集計結果が少し違うみたいなことが起きます。
UIなら違和感で気づくことでも、APIでは見逃すことがあると思います。
例えば税計算でも、計算方法によって結果が変わることがあります。
税抜334円の商品が3つあり、税率が10%だとします。
商品ごとに税額計算（端数切り捨て）すると
334 × 10% = 33.4 → 33円なので
33円 + 33円 + 33円 = 99円になります。
しかしインボイス制度では税率区分ごとに税額を計算する必要があります。
つまり
334 × 3 = 1002円
1002 × 10% = 100.2 → 100円が正しいです。
このように計算方法を少し変えるだけで、結果が変わってしまいます。
もしテストがなければ、この差分に気づかない可能性があります。
こういうケースこそ、このシステムでは税額はこう計算するというテストケースを作成しておくことで仕様を保証することができます。
個人的にかなり納得している言葉です。
ドキュメントって、どうしても古くなりますし更新していくのも大変、、無理、、できない、、、
仕様や設計を書いていても、実装が変わるとか、ドキュメント更新されないということがよくあります。無理もないと思います。
でもテストは実際のコードを動かすので挙動を保証して、壊れるとテストが落ちるんですよね。
つまり実装と必ず一致しているドキュメントになります。
ほとんどの現場でテスト全部通らないとCI落とす→マージできないって流れなんじゃないかと思います。
テストがあると、リファクタリング、クエリを改善、ロジックの整理ができるという安心感があります。
リファクタしようってなった時に、テストがないと不安で仕方ないと思います。
綺麗にしただけのつもりが壊していないという保証がないからです。
コードは未来の自分や、チームメンバーが触るものです。
だから最近は自分たちのためにテストを書いているという感覚に近いです。
AIがコードを書く時代になっても、このシステムはこう動くという仕様は人間が定義する必要があります。
その仕様を一番正確に表現できるのがテストなのかもと思います。(テスト駆動開発ですね〜)
宣言的にこの場合、こうなるって淡々と定義してその通りの振る舞いになるか、そこがパスできてたら動作は問題なさそうだってわかりますもんね！
フロントエンドでは画面で確認できるし手動で振る舞いのテストしやすいので、ある程度安心して開発できます。（テストなくていいって意味ではないですが）
でもバックエンドでは挙動が見えないですし、小さな変更で結果が変わる上に間違いに気づきにくと思いますし、業務ロジックなのでミスった時の影響がでかいと思います😇
だからこそバックエンドではテストが安心を作ると感じています。
最初は毎回テストめんどいなって思ってましたが、仕様の変更への対応、リファクタ、ミスれない計算ロジックなどのテストを通じてありがたい存在になりました！
要約
コメント
まだコメントはありません。
