2021/06/14
はじめに
私は，一度 OSS に新機能のプルリクを出したことがある．
その時，最初は新機能のみをプルリクに出していたのですが，OSS の保守性を高めるために，モジュールの単体テストをセットで追加する必要があるとのこと．
テストがあれば，バグの再現が可能なテストを追加して，バグを洗い出したり，コードの変更があったときにもテストに通過を維持することで，新たなバグを埋め込みづらくする事ができるようである．
ちなみに，私が開発した機能は C++で記述し，テストには Google Test を用いた．
実際の流れ
実際に行った開発の流れは以下のようになる．
- 追加する機能を決定
- 機能を追加
- 目視で必要な機能を満たしているか確認
- 機能が満たすべき要件を洗い出す(入出力)
- 入出力を文字にする(簡単な入出力・境界条件など)
- 使うユニットテストフレームワークを決定
- テストを書く
- テストを通過するか確認
意識すること
入出力を作る時，特殊な入力が考えられる場合は，できるだけ網羅するようにテストを書いたほうが良い．
また，アルゴリズムに対するテストを考える際に，真逆の処理を行うコードを書いて，お互いの入出力が一致するかを確認するという手段もある．
おわりに
これからは，自由に書く自分のコードでもできるだけテストを書くように心がけたい．(特に書き捨てではなく継続的に更新する予定のコードは)