既存機能の信頼性を担保してから変更を行う
本日の学び
開発フローにおけるテスト観点について、新たな学びがあった。
今回はやや複雑な事情になるため、整理しながらまとめていく。
開発アイテムが既存の機能の拡張を行う
すでにある機能に手を加えて新規機能を追加した。
既存機能は、データの操作が複雑化されていて、新たな処理を加えた場合の影響範囲が広いため、
既存処理を改修していく形式で（スケジュールの都合上）行っていった。
開発 > テスト > レビュー を経て、トピックに取り込まれ、ステージング環境で再試験したところ、バグが発覚した。
バグの原因は改修範囲内のコードだったことが判明し、無事修正が行われた。
なぜ単体での開発時に気がつかなかったのか。
原因は2点。
つまりステージング環境のDBは本番では想定していないようなデータセットになっていて、
そこが起点で既存機能に含まれているバグをあぶり出す形になった。
当然、このまま本番へデプロイしていたら普通に動いていただろう。（ローカルで正しいデータセットなら動いていたため）
ある意味仕方がなかった話ではあったが、教訓と対策を得ることができた。
既存機能（ブラックボックス）はバグを内包している可能性が常にあり、今うまく動いている前提条件をきちんと明示的にしておかないと、（メンバーが入れ替わった際など）後々バグを生みやすくなる、ということ。
これは内部仕様書やユニットテストでカバーしたく、今後の開発フローにおけるレビューでチェックしていきたい。
また実装するフェーズにおいて、すでに動いている部分を全面的に信頼するのではなく、
うまく動いているように見えている可能性も考慮し、データフローに関する精読・(欠けていれば)ユニットテストも追加し、既存機能の信頼性を担保してから、改修を進めていくことにする。
