こんにちは。エンジニアのaです。
最近仕事でコードを書く際はなるべくテストを書くようにしています。
その雑感をお伝えします。
私が開発に携わっているシステムは歴史が長く、もちろんテストエンジニアによる手動テストはしっかりと行われているのですが、自動テストは行われていないor過去に作られたものはあるが動かないという状態でした。
テストの選択
自動テストといってもJUnitを使った単体テストやSeleniumを使ったUIテストなど多々あります。
今回は単体テストを書きました。
単体テストから始めて、単体テストで解決が難しい部分があった場合にはじめて他のテスト方法も併用する方がよいと考えたためです。
どこからテストを書くか
単体テストを書くとしてどういったクラス/メソッドに単体テストが有効かを検討しました。
もちろん理想的にはすべての処理にテストがあることが望ましいですが、既存のコードベースのテストを１から書いていくことは難しいと感じました。
また、既に正しく動作しているものを再テストするのは工数的にも厳しい面があります。
そこで、新規機能を開発する際になるべくテスタブルなクラスを作り、この限られたクラスのテストを書くというところから始めました。
単体テストがとくに有効な処理として以下が挙げられると思います。
・複雑なビジネスロジックを含んでいる
・処理がクリティカルである(例えば銀行のシステムでいえば送金処理のような、絶対に間違いがあってはいけない部分)
・画面操作でのテストが困難
テストを書くにあたっては、なるべく上の性質を満たすようなロジックのテストから書いていきました。
既存のテストでカバーできない範囲であれば、比較的周囲の理解がえられやすいのではと勝手に思っています。
単体テストでカバーできない範囲
テストを導入してみて、以下のようなバグは単体テストでカバーするのが難しいと感じました。
仕様レベルでのミス（不理解、勘違い等）
要件が複雑で仕様レベルでの理解が足りない場合は、単体テストで発覚するということはあまりありませんでした。
これはテストの書き方にもよると思うのですが、今は実装後にテストをしており、テストが実装に引きづられるところがあります。単体テストは意図した実装が正常に動くかの検証には有効ですが、実装した考え方自体に誤りがある場合は誤りを見つけられませんでした。
SQLが絡む部分
SQLにビジネスロジックが漏れ出しているところがあるのですが、こういった処理は単体テストではカバーできません。
UI
UIも当然単体テストではカバーできないので、現在は手動テストが基本です。今後Seleniumを使って自動化を進めるのもありかもしれません。
Seleniumは以前プロジェクト内で試された形跡がありコードも結構残っているので、これを動かすところから始めるのが良さそうです。
テストを書くことの弊害
最後に、単体テストの弊害についても述べておきます。
意味のないテストを書くと改修時の保守コストだけが増大することです。内部でやっている手続きをそのままテスト化するようなテストもいくつか書いたのですが、こういったテストはあまり意味がないと感じました。
最後に
まだCIができていないので、今後の課題といえそうです。