現在社内で既存処理のリプレイスを行っています。
開発の中で既存処理のテストを行おうとしたときに困ったことが出てきたのでそのことについて書いていきます。
何が困ったのか
- 既存のテストケースが様々な場所散らばっている
- テストケースの内容が更新されていない
- 既存処理の仕様が残っていない
既存のテストケースが様々な場所散らばっている
既存の処理のテストを行うにあたり、まずは過去のテストケースをまとめる作業から始めました。基本的に社内のドキュメントはGithub上で管理していますが、古い機能はその限りではありません。社内の共有フォルダ・googleスプレットシート・さらには各個人のローカルに眠っているケースもあり、テストケースをまとめるのにかなりの時間を要してしまいました。
テストケースの内容が更新されていない
チームのエンジニアの記憶等を参考にしつつ過去のテストケースをひとしきり集めた後、中身を確認していくと現在の仕様とテストケースが合わない箇所が多々あることがわかりました。複数人のエンジニアが改修を重ねているので当然ではあるのですが、都度ドキュメントが更新されているわけではないのでいざというときにやはり困ってしまいます。
既存処理の仕様が残っていない
中にはテストケースが残っていない機能も存在します。この場合テストケースの作成が必要になるのですが、そもそも仕様が残っておらず挙動が正しいものであるのか細かいバグが放置されているものなのか判断がつかないものがあります。それでもテストをしないわけにはいかないので、どうにかテストケースの作成を行わなければなりません。
結果どうしたのか
- テストケースを作成しなおす
- 仕様がわからないものに関しては現在のコードを正とする
- バグか判断がつかないものについては運用を担当しているチームとすり合わせを行い現状の正しい挙動を定義する
今回は社内のエンジニアの皆さんの力をお借りしつつテストケースの作り直しを行いました。合計で2000ケースほどのテストケースになりましたが、現状のサービスの大体の部分をカバーできるテストが作成されたと思います。ご協力いただいた皆様ありがとうございます。
良かったと思うこと
現状動いているコードをいったん正としてテストケースを作成するのが効率が良かったと思います。もちろんバグがある箇所もありますが、運用担当のチームとすり合わせることで正しい挙動を定義できるとともに今後改修しなければならない箇所の洗い出しにもなりました。現在テストの結果とともに細かいバグのリストをスプレットシートで管理を行いリスが作成されています。リストの内容を改修した際に、今回作成したテストケースが更新できる形になっているのでこれまで起こっていたドキュメントが更新されない問題が解消されていきそうです。また、機能ごとにテストケースをまとめたので現時点での最新のテストケースが一か所に集約されました。これで既存機能のテストを行うときに余計な時間を減らすことができていきそうです。
終わりに
ほぼ最近大変だったことの感想になってしまいました。
次はテストの中身についてもう少し詳しい内容で書いていければと思います。
（パラメータの組み合わせのみ書かれていたり、遷移図があったりなかったり、想定結果が書いていなかったり）
さんざん書きましたが、過去のテストケースの中には自分が作成したものも含まれており、とても反省したのでこれからはドキュメントを適当に終わらせないようにしたいと思います。