テストケースはメンテが大事だけど、メンテ難しいよね？

テストケースをメンテナンスしたり、管理するのは継続プロジェクトにとっては重要。当たり前なので、いちいち言うのもあれなんですが、機能追加だったり改修だったりが入ってくると新たにテストケースを起こすことももちろん有りますが、再利用出来たりすると捗るよね。とくに単体テスト JUnit のケースだったりとか。

一方で、ファイルサーバー上に残るのはテストケースが書いてあるExcelだったり、JUnitのコードだったりするのでとても見通しが悪く、メンテしにくい。結果として何が起こるかというと、デグレ。

今日のエントリはメンテ大事ね、という話。オチ無し。

主担当がいなくなるという潜在的リスク。

ただ、これって潜在的なリスクで、なかなか顕在化しないことが多い気がする。何故かというと、担当者がずっと同じならある程度経験で避けられるからだ。逆に変わったりすると大変なことになる。自分が今やっているプロジェクトは、急遽私に担当変更になったんだけどデグレしそうになったこと複数回。。

マネジメントの問題もあるけど、自分がいなくても回る仕組みを作るのもエンジニアの大事な仕事。

メンテがし難い理由。中間成果物が無い！

閑話休題。話題を元に戻すと、過去のテストケースやJUnitのコードだけでメンテがし難い理由は、具体的には、 中間成果物が無い のでケースをどういう意図や手順で作ったかがわからないからだと思う。

例えば、ブラックボックステストで、同値分割して、直交表書いて、ケース起こしたそしても、どう同値分割したか、直交表をどう書いたかが無いと、ケースを見ただけでは意図がさっぱりわからないことがある。こういう中間成果物って往々にして、テストケースを作った人がメモってたりするんだけど、しばらくすると霧散しちゃう。

もちろん、ちゃんと丁寧に読みこめばわかるんだろうけど、漏れるよね。私は、注意散漫気味なので漏れる（笑）あと、直交表とか状態遷移図とか、デシジョンテーブルとか、元が無いと読みとくのがどんどん辛くなってくる。それに、文章ではなくて表になっていないと、ケースって往々にして漏れるよね。特にJUnitのコードとか。

CIとかアジャイルとか。

これって、CIの考えに抜けていると思っていて、つまり、テストを自動化していてもメンテが容易でないとメンテされなくなり易いと思う。

先日、ant のテスト自動化の記事を書いたけれども、自動化して何が起こったかというと、コード修正→単体テスト実行→赤→赤くなったケースを見なおして、仕様に合うように修正→再テスト→緑という作業のループになる。このやり方は、既存のケースでカバーしていない範囲のテストは、確実に漏れる、テストされないってこと。あらラララ。。。