テストケースのコーディングが不要！ Test Case Editor

単体テストの最大の課題とは？

単体テストが必要であることは認識している。でも時間がないので現実は… という開発現場は少なくないと思います。

単体テスト工程における最大の課題はテストケースのコーディング作業とされ、ツールを使用しない場合、 そのコーディングの量はテスト対象のソースコードの 3～5 倍とも言われています。

テストケース、スタブのコーディングが不要！

C++testの最新バージョンではソースコードを記述せずにテストケースを作成できる「Test Case Editor」が新たに搭載されました。

Test Case Editorを使うと、コーディングを行うことなく、テストケースとスタブを作成することができます。またテストケースの入力値／期待値、スタブの振る舞いなども独自のGUIから設定することが可能です。

さらに、テストケースのメンテナンスもGUI上で行うことができるため、テスト対象が変更される度にテストケースのコードを修正するといった煩雑な作業から開発者を解放します。

高機能なスタブ

Test Case Editorを利用することで、コーディングを行うことなく高機能なスタブを作成することが可能です。 例えば、渡された引数に応じた戻り値を設定するなど、複雑な振る舞いをGUI上で容易に組み込むことができます。

条件に応じて、オリジナル関数をそのまま呼び出す／スタブの処理を実行するを切り分けることもできます。 これにより、標準関数の処理が失敗した場合などの異常系の動作検証を簡単に行うことができます。

TÜV SÜDによる認証

C++testは、第三者試験認証機関であるTÜV SÜD社よりISO 26262（自動車の機能安全についての国際規格）、IEC 61508（機能安全の国際規格）に準拠したテストツールとして認証を取得しております。最新のC++test 9.6においても、認証を再取得いたしました。
テストツールが認証を取得していない場合、ユーザーは規格の要求に応じて、第三者試験認証機関に認証を依頼し、認証を取得するための時間や費用が必要になります。C++testは認証のためのコストを削減します。

無償体験版をお試しください

これらの機能は、無償体験版にてご確認いただけます。
まだC++testをご利用いただいていない方は、この機会にぜひお試しください。
C++testの機能概要、稼働環境は以下をご覧ください。

・単体テスト
・コーディングルールチェック
・フロー解析
・実行時メモリエラー検出／アプリケーション実行時カバレッジ
・最新の稼働環境

※本文中に記載されている製品名、および社名はそれぞれ各社の商標または登録商標です。

C++test 体験版ダウンロードは ↓ こちら ↓です。

ソースコードに技術的負債を溜め込んでいませんか？

“とりあえず動く”コード

　納期間際になって不具合が見つかった状況を考えてみます。選択肢は2つあります。一つは設計から見直し、コードを変更してテストも行うことですが、納期に間に合わないかもしれません。

　もう一つはとりあえず不具合を解消するよう深く考えずにソースコードを変更することです。納期に間に合ってプログラムも正常に動いている模様ですが、その後の変更時に影響範囲が大きかったりソースコードの意味が分からなかったりして、不具合の修正や機能追加が大変になる、あるいはコードをいじれない、という事態が待ち受けています。

　あなたのプロジェクトは2つ目のような事態に陥ってはいませんか？

技術的負債とは？

　2つ目の選択肢のような「とりあえず動くが、後から変更が大変なコード」は「技術的負債」と呼ばれています。技術的負債は単にソースコードが汚くて読みにくいコードだけでなく、次のようなコードも当てはまります。

• テストケースが作られていないコード
• 設計を推敲せずに書かれたコード
• 別のところからコード断片をコピー＆ペーストしたコード

　これらが溜まってくると、コードを修正して良いのかどうか、何のためのコードなのかが分からなくなってきます。その結果、次のような問題に発展していきます。

• 変更に時間がかかる
• テスト工数が膨らむ
• リリースが遅れる
• リリース後も障害が起きる

　このような問題に発展する前に、リリースまでに技術的負債を極力減らしておく努力が必要です。作られてしまった技術的負債を減らす方法は唯一、リファクタリングを行い、地道にコードをきれいにすることです。しかしリファクタリングを行うにも工数が必要ですから、技術的負債の量や、技術的負債に対処しなかった場合のビジネス上の影響、プロジェクトの進捗などといったものとのバランスを見て行わなければなりません。

技術的負債の計測と可視化

　では技術的負債の量はどのように求めたら良いでしょうか？　技術的負債の構成要素としては、コーディング規約違反の件数、メトリクスの超過/過少の量、単体テストの失敗件数、テストで未到達なコードの量、等が考えられます。一例として、SQALEメソッドにおいて技術的負債の計算方法が例示されていますので、参考になると思います。

　技術的負債を定義したら、次は技術的負債の構成要素を計測します。計測方法は要素によって異なりますが、コードレビュー時に確認したり、単体テストを実行したり、静的解析や構造解析のツールを利用することが一般的です。弊社取扱製品であるParasoft JtestやParasoft dotTEST, Parasoft C++testといったテストツールももちろん利用できます。

　最後に、各要素から技術的負債を計算してプロジェクトメンバーに提示します。先程例として挙げたSQALEメソッドに従うと、技術的負債は単純な四則演算で計算できますので、表計算ソフトでも計算できます。あるいは弊社取扱製品であるParasoft Development Testing Platform (Parasoft DTP) を使用すると、技術的負債を計算する手段が予め提供されている他、技術的負債がモジュールや品質特性ごとに計算され、かつWebブラウザで確認できます。WebブラウザでParasoft DTPにアクセスすれば、下図のようにどこにどれくらいの技術的負債が溜まっているかをいつでも誰でも確認できるため、技術的負債を減らすためにリファクタリングを開始する動機付けが可能になります。

　また、継続的インテグレーションの中に技術的負債の計測を組込むことで、現在のプロジェクトの技術的負債の状況をリアルタイムに近い形で確認することが可能になります。技術的負債が増加していることをリアルタイムに把握できれば、リーダーの方がリファクタリングを開始するよう指示して早期にプロジェクトを軌道修正することも容易に可能になります。

技術的負債を計測しませんか？

　いかがでしたでしょうか。技術的負債とは何か、技術的負債が溜まるとどうなるか、技術的負債を算出して可視化する方法をご説明いたしました。読者の方が技術的負債を返済し、将来の変更の労力を少しでも減らすことができればと思います。

　最後に、上記で紹介しました弊社取扱製品はすべて2週間無償でご評価いただけますので、購入を検討されたい方は下記からぜひお試しください。またParasoft DTPのユーザー様向けに、技術的負債を計算するためのプラグインも提供しておりますので、ぜひご利用ください。



Parasoft DTPプラグイン提供ページ