私はプログラムエンジニアをしております。

Question

私はプログラムエンジニアをしております。仕事の中で疑問に思った点があり、内容もこういう所でしか聞けないため質問させて下さい。(初歩的な所になってくるかと思います。)

前提
まず初めに使用言語はCOBOLです。
今回は項目に値を代入する改修ではなく、判定値によって分岐するロジックの確認作業になります

質問
改修で発生したUTテストにおいて入力値、想定値（ここでの想定値は改修場所のステップ行を追加した時のもの）などを盛りこんだ仕様書を作成しているのですがいざプログラムを実行ドライバで動作をさせて確認する際に必ず疎通のチェックが入ります。この作業がかなり面倒で私が過去に作成したソースではない為時間がかかってしまいます。既に一時リリースを終えたソースの内容であるから省けないかな？っと思いました。
そこで無理やりではありますが改修前のステップ行にMOVEなどを使用して値を代入しUTケースの確認するのはダメなのでしょうか？（ここでリリース用の作成物は一旦別の場所に保存し、複製したものを一時的に今回のような確認用として作成しているものとします）上司からは作業指示が出ているため今回の有無とわずやる予定ではありますが、なぜそのやり方でやるのか？といった部分でまだまだ経験が足りておらず理解できていません。
今回の改修範囲ではない別の場所の致命的ミスを事前に防ぐための措置？かなと思いましたがこの他で何かあれば解答いただけると助かります。

Answer 1

UTテストはユニット(単体)テストの略でしょうか？
だったら、単体テストの体をなしていませんね。

普通、単体テストでは何かに依存するとき、mockを作成します。
“MOVEなどを使用して値を代入”みたいなことをmockにやらせるわけです。
テスト用のフレームワークを使えばこういったテストを実現できます。たぶん。

COBOLはもう過去の遺物と化していて、関わっている人たちもけっこうな年齢です。
他の言語やフレームワークで当たり前にやられているテストの方法が受け入れられないかもしれません。

Answer 2

効率化できる部分は行った方が良いですが、面倒だから省きたいという理由であれば、試験の意味がありません。

確実にその部分は修正の影響が無い、ということを全員が納得するだけの根拠を説明すればいいかもしれませんが、そこに使う労力、上司や同僚に「そのようなことは出来ない」と反論されることを覆したり、結局受け入れざると得ないときの精神的苦痛を考えると素直に試験した方が良いと思います。