うちのチームのテスト事情

うちのチームのテスト事情について、反省を含めてまとめてみます。

いわゆるビジネスロジックを作ってます。↓の青いところです。

結合テスト
- クライアントのAPIを叩いて、クライアント-サーバー-DBの結合動作をテストする。
- 工数を割いて網羅的に実施。
- ただし、クライアントから実行して試すのが難しい操作(処理の途中でDBが落ちた場合とか)はテストに含めていない。この辺は、モックを利用した単体テストで補完する必要があると思う。
単体テスト
- クラスごとの単体テスト。
- 独立性が高く結合度の低いクラスについては行なっている。DAOを使うクラス(ロジックとか)は、単体テストはしていない。(結合テストでカバーする、という考え)。
- 本来はDAOのモックを用意してテストするべきなんだろうけど、それだけの工数はとれていない。
性能テスト
- 十分なパフォーマンスがあるかのテスト。
- よく使われる操作についてのみ。網羅的には行なっていない
負荷テスト
- 多重度を上げてもちゃんと動くかのテスト。
- よく使われる操作についてのみ。網羅的には行なっていない

UIからの結合テスト
- UIチーム任せ。
受け入れテスト
- リリースされた依存モジュールがこちらの要求する仕様を満たしているかどうかのテスト。
- DAOなんかは他のチームが作成しているモジュールだけど、受け入れテストは特に用意していない。まぁ、チームは違うけど同じ部署だし、そこまで信用してなくはないです、といったところ。別の部署や外注したモジュールとかなら必要だろうな、とは思う。
テストカバレッジ
- 100%とか目指して、geter,seterのテストとかいちいち書いたりする暇はありません。かといって90%とか謎の数字を導入するのもアレだし。もっと有意義なテストに注力すべきと思う。
- 網羅性の目安としては使えると思うんだけどね。ただ、「必ずXX%達成!」といった規約にはなっていません。
テストファースト
- やってないなー。
- 実装で事故があっても最低限モノはできているように、先に実装して残った時間でテストするという流れになってしまっている。
- ただ、スケジュールをずらしても最低限結合テストは書くようにしてます。

結合テストは作成しているけど、網羅性は低いなとは思う。
- 特に異常系。
この辺は単体テストでカバーすべきと思うけど、コスト的になかなか厳しい。
- 「1クラス1テスト」とか夢のまた夢。
- ロジックのテストとか、いちいちモックとか作ってられんて。JMockとかユーティリティはあるにしても、依存ジュールの動作をエミュレートするのはなにげに大変だし。
まぁ、結合テストを補完する目的に沿って、ポイントを押さえた単体テストを充実させていく、というのが現実路線かと。
性能テストや負荷テストはもうちょっと網羅的にやるべきだと思う。あと自動化もしたい。性能計測とか、なんだかんだで繰り返し測る場合が多いし。
- このへん、開発担当者本人じゃなくて別のチームの人とかアルバイトさんがやってる、とかいう事情はあるんだけど。
あと、すべての結合テストの実行に2,3時間かかるのはそろそろ何とかしないと。