はじめに
業務で「仕様化テストを書こう」となったが、正直「仕様化テスト」というワードを筆者は初めて聞いたものである。
本記事では筆者の学習メモのような形で記載する形となるので、筆者なりの理解になってしまう部分があるのをご了承いただきたい。
今回学習にあたって読んだ本
今回学習にあたって読んだ本は「レガシーコード改善ガイド」である。
本著はレガシーコードを改善するためのリファクタリングを行う手順や単体テストに関する著書となっている。
仕様化テスト以外の内容については本著を手に取ってみてほしい。
Amazonの購入サイト
仕様化テストとは
レガシーコードをリファクタリングするためには、ソフトウェアの仕様を調べ、その結果に基づいたテストを書くべきである。
この時仕様の振る舞いを維持するために必要なテストを仕様化テストという。
そのためには現在のシステムの振る舞いをそのまま文書化することが必要である。
また文書化の際に怪しい動き、仕様化として明示化されていないものはテスト対象に含めないのではなく、コードの調査を行い、対象に含めるべきである。ブラックボックスではなく、ソース上の振る舞いを調査し、併せてテストを書くという手法が仕様化テストである。
この時コードに必要と考えられるテストケースをできるだけ沢山書くこととテストを書いた後、変更したい具体的な事柄について調べることが大切である。
～作成の流れ～
仕様化テストを書くためには以下の手順で書く必要がある
1.JUnitの中で対象のコードを呼び出す
2.失敗すると分かっているテストコードを書く
3.失敗した結果から実際の振る舞いを確認する
4.コードが実現する振る舞いを期待するようにテストを変更する
5.1〜4を繰り返す
業務で導入するにあたっての所感
レガシーコードにはそもそもブラックボックス化されていて、誰も知らない謎の仕様というものが沢山ある。
その中で不具合修正だけでなく、その他の業務でも仕様も紐解くというシーンは多々ある。
しかしテストを書くということはどうしても別物と考えてしまいがちである。
そのためまずは仕様を調べることとテストを作成することをセットという意識付けから始める必要があるという所感である。
おわりに
今回仕様化テストについて学習をしたが、実践的な部分はまだまだ足りていないと感じている。
実際の業務で得たノウハウなどは是非追記か別記事にしていきたい。