Javaの改修前に確認したい、影響範囲とテストの考え方

こんにちは。グロトムの堀口夏希です。小さな条件変更でも、修正する行数と影響の大きさは一致しません。今回は、Javaの業務システムを想定したオリジナルの練習例で、改修前の確認を整理します。

まず、変更するルールを一文にする

例題は「注文金額が5,000円以上なら送料を無料にする」という変更です。ここで先に決めたいのは書き方ではなく、注文金額の意味。税込か税抜か、割引の前か後か、送料自身を含むかで、同じ5,000円でも結果が変わります。

この例では「割引後・送料を含まない税込商品合計」を整数の円で受け取り、5,000円未満は送料500円、それ以上は0円とします。負の金額はエラーにする前提です。実務では、この前提を業務担当者や設計書と照らして確かめます。

何を変えるかと、何を変えないかをセットで書く。 通常配送だけが対象なら、特別配送のルールは維持することまで明示すると、調査の範囲が定まります。

修正箇所から、呼び出す側と使う側へたどる

送料計算メソッドを見つけたら、その中だけで調査を終わらせないようにします。注文確認画面、注文確定処理、管理画面での再計算、夜間バッチなど、どこから使われているかを確認します。

さらに、計算結果を受け取る先も見ます。請求金額、確認メール、帳票に別の計算や表示処理があると、画面は0円なのにメールは500円という不整合につながります。

検索で見つかった箇所は「変更が必要」「回帰確認だけ行う」「今回の対象外」に分け、理由を残します。文字列検索だけでは見つからない設定や外部連携もあるため、設計資料や詳しい人への確認を組み合わせます。

境界値を、実装より先に並べる

この練習例の期待値は、4,999円なら送料500円、5,000円なら0円、5,001円でも0円です。0円は500円、負の金額はエラーとします。「5,000円ちょうど」を入れると、比較条件の取り違えを見つけやすくなります。

テストの期待値は、実装を見て追認するのではなく、合意したルールから決めます。 同じ計算式をテスト側に写すだけでは、同じ誤りを再現するおそれがあります。

ここでは整数の円だけを扱います。小数、税計算、丸め、nullを受け取る仕様がある場合は、別の論点として入力条件と期待する扱いを決めます。

単体テストで終わらせない

計算メソッドの単体テストに加えて、画面から渡す値が「割引後」の合計になっているかを確認します。割引前5,200円、割引後4,800円なら、この例の送料は500円です。メソッド単体が正しくても、渡す値が違えば業務上は誤りになります。

注文確定後の保存値、メール、帳票まで同じ金額になっているかも確認対象です。一方、今回変更しない配送区分については、既存の期待値が保たれるかを回帰テストで押さえます。

レビューに持ち込むのは、差分と根拠

レビューでは、変更したコードと一緒に「業務ルール」「調査した呼び出し元」「境界値の結果」「確認できていない点」を短く渡します。不明点を残したまま完了扱いにせず、誰と何を確認するかまで整理すると、次の行動が明確になります。

改修前の調査は、書き始めるまでの準備であると同時に、変更を説明するための土台です。設計や改修の経験を次の仕事につなげたい方は、Javaエンジニアの募集もご覧ください。