mhlyc -practice

ソフトウェアテストと品質保証がメインテーマです。

ユニットテストとデバッグの難しさ

※あくまでここの話はアジャイルプロジェクトではなくウォーターフォール型の開発プロジェクトの前提で書かれています。

 

ユニットテストの難しさ

私が開発者になって強く思ったのがユニットテストが多くて面倒くさいということです。そしてユニットテスト勘や経験に頼って設計している開発者もいます。

if文に数値の大小比較の条件文が書かれていたとして、それに対して境界値を考えてテストケースを出すとか、そういうのをやっていない人が一定数いる気がしています。また、テストコードをどう書くべきとかも、思ったより体系だった情報がないように感じました。(書籍はいくつかあるようなので、あとで読んでみることにしています)

デバッグの難しさ

バグの修正をユニットテストに含むのかというと、それはテストではなくデバッグであるから含まないのでしょうが、このデバッグでも困っています。

バグを見つけたとして、どう直すのか? バグの修正というとチャチャっとやってしまえそうに聞こえますが、実際は設計から間違ってるとか、作りがイマイチで色々作り直すハメになるとか、色々あります。そこで変な直し方をすると、色々ぶっ壊れてスパゲッティコードの出来上がりです。こんな地獄のようなユニットテストを終えて結合テストに入ると、当然バグが収束せず、この時点でコードレビューをしたってもう手遅れも手遅れです。

 

私は今すごく派生開発におけるユニットテストデバッグに対して色々な課題を感じています。派生開発において保守性を維持しつつ必要なテストと修正を行うのはかなり難しいと思います。

もちろん良いコーディングやテストを開発者は学ぶべきだし、開発者がそこまで考えてコーディングできたらいいですが… 実際のところ難しくて、だからこそ保守しづらいコードになっていたりするのではないでしょうか。例えば生産技術チームだったりQAチームが、そのあたりのサポートをしてくれると僕はとても嬉しいと思います。