タダでソフト開発の生産性と品質を上げる方法（4）：単体テストで威力を発揮する「MinUnit」：山浦恒央の“くみこみ”な話（94）（1/3 ページ）

「タダでソフト開発の生産性と品質を上げる方法」の第4回。今回は、単体テストで威力を発揮する「MinUnit」を紹介する。

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

1．はじめに

　出荷後、顧客サイトでソフトウェアのバグを出さないためには、開発中にたくさんバグをたたき出しておく必要があります^＊1）。このためにはシステマチックなテストが重要で、通常は、モジュールレベルの単体テスト、ひとまとまりの機能をテストする結合テスト、システム全体を検証する統合テストの3段階構成で進めます。

　今回は、これら3つのテストの中で最も数が多くて時間がかかり、ソフトウェア開発技術者が最も嫌う単体テストで威力を発揮するツール「MinUnit」を紹介します。MinUnitは、最小限の機能で大きな効果を期待できます。

＊1）製品のテストが一通り完了し、「ほぼ正常に動作する」段階になると、「α版」として顧客に提供することがあります。α版をリリースする目的は、「正式版ではないが、お試しに使ってください。使い勝手に問題があったりバグがあったら教えてください。可能な限り対応します」です。

　ソフトウェア業界の口の悪い連中の中には、「マイクロソフトの『Word』は、α版を世界中にリリースしているのではないか？　世界中の数億人の顧客に実環境で最終テストをしてバグを報告してもらい、それをベースに品質改善をしているように思う」と言う人もいます。長時間かけてWordで作った文書が、バグのために一瞬で消えてしまうと、確かにそう思いたくなりますね。

　私は逆に、「α版を世界中にリリースして、みんなでバグをたたき出してもらう」のは、新しい開発モデルになり得ると思っています。顧客は、「バグがあるリスクを覚悟しながら新プログラムを早く入手」できますし、開発側には、「短期間で、広く細かいテストを実践的に実施できる」という利点があります。「ウォータフォールモデル」「スパイラルモデル」のように、開発モデルになるかも知れません。「開発ドキュメントを作る時間と労力を最小限にし、なるべく早くコーディングする」という開発モデルを整備、理論武装して「アジャイルモデル」となり、広く適用されているように、「α版リリースモデル」を誰かが確立してくれることを望んでいます。

2．単体テストの利点

※写真はイメージです

　出荷後にソフトウェアのバグ出さないための第一段階が単体テストです。1つの関数ごとにテストする単体テストでは、可能な限り、単純なバグを摘出する必要があります^＊2）。単体テストの利点は、バグが発生した時、容易に修正できる点です。例えば、ある関数でバグが見つかっても、影響範囲は基本的にその関数のみとなります。100行程度のソースコードをチェックすればいいので、修正は簡単ですね。

　エンジニアの中には、開発スケジュールを短縮するため、「いきなり統合テストやってしまえ」と考える「勇者」も少なくありません。関数をまとめて結合してテストすれば、システム全体の挙動を早く確認できますし、ただでさえ少ないテスト工数を有効に使えます。この考えは一見正しそうですが、単体テストをサボったツケは、キチンと見事なまでに統合テストで現れます。統合テストは、関数を組み合わせてテストすることで、単体テストと比べて関数や変数の影響範囲が急激に広くなります。単体テストをスキップして統合テストに入ると、単体レベルで摘出すべき単純なバグに悩まされ、タップリ苦労するはずです。

　上記のことが十分分かっていても、単体テストは面倒です。そんなエンジニアのために、今回は、MinUnitという超軽量な単体テストのフレームワークを紹介します。

＊2）組織によって、単体テストの定義は異なります。本コラムのように関数単位のテストを指すこともあれば、まとまった関数であったり、1画面のテストを単体テストと考える会社もあります。今回は、1関数ごとのテストとして説明します。