実務で効くテスト戦略とアンチパターン
ここまでで、RSpec・FactoryBot・CI という基本装備は整いました。
しかし実務では、
「テストを書いているのに、安心できない」
「テストが増えるほど、変更がつらい」
という状況に陥ることも少なくありません。
その原因の多くは テストの書き方 にあります。
よくあるテストのアンチパターン
① 実装に依存しすぎたテスト
expect(assigns(:articles)).to eq Article.all
このようなテストは、内部実装を少し変えただけで壊れます。
テストすべきなのは「どう実装したか」ではなく、
「ユーザーにとって何が保証されるか」
です。
② 1つのテストで確認しすぎる
・DB更新
・画面遷移
・エラーメッセージ
・副作用の確認
これらを1つの it に詰め込むと、
失敗時に「何が悪いのか」が分からなくなります。
テストは小さく、意図が1つが鉄則です。
③ テストのためのテスト
・Factoryが複雑すぎる
・前提条件が多すぎる
・読むのがつらい
こうなったテストは、
「守るための保険」ではなく「足かせ」になります。
良いテストの共通点
実務で評価されるテストには、共通点があります。
・テスト名を読めば仕様が分かる
・失敗したら原因がすぐ特定できる
・変更に強い
例えば、
it "公開済みの記事だけが一覧に表示される"
この1行だけで、
「何が仕様で、何を守っているか」
が明確に伝わります。
テストはドキュメントでもある
という意識が、品質を一段引き上げます。
テストが書けないときのチェックリスト
もしテストを書く手が止まったら、
次の点を疑ってみてください。
・責務が1つにまとまっていない
・依存関係が多すぎる
・入力と出力が曖昧
これは「テスト力」の問題ではなく、
設計の問題 であることがほとんどです。
テストは設計の鏡です。
テストしづらいコードは、
将来必ずメンテナンスコストになります。
テスト文化がチームを強くする
テストは個人スキルだけでなく、
チーム文化 にも大きく影響します。
・レビューで安心してOKが出せる
・新人が仕様を理解しやすい
・属人化しない
「テストがあるから任せられる」
この状態を作れるエンジニアは、
技術以上に信頼されます。
次回予告
次回は、
「保守し続けられるRails設計とリファクタリング」
をテーマに、
・技術的負債との向き合い方
・安全なリファクタリング手順
・実務でよくある改善例
を解説していきます。
「書いたコードを、どう育てていくか」
ここを理解できると、
Railsエンジニアとして一段上の景色が見えてきます。
テストと設計を武器に、
“動く人”から“任される人”へ。
次回も、一緒にレベルアップしていきましょう 💪✨
ヘッダー画像の引用元
UnsplashのGlenn Carstens-Petersが撮影した写真
この記事はChatGPTを用いて作成されました。
コメント 0件