*

middle_unit
最小…よりも(ほんの)少し大きいテストフレームワーク

公開日: : C言語, テスト, 開発

どもです。

今回は、単体テストのフレームワークについて書きます。

1.最小のフレームワーク

世の中に数多ある単体テストのフレームワークの中で、最も小さいモノは「min_unit」であると考えています。
(あくまで、私個人の意見/見解です。)
詳細は、コチラのサイトを参照してください。
このテストフレームワークは、たった1つのヘッダファイルのみから構成されています。
加えて、実装されているのも、「mu_assert()」と「mu_test_run()」の2つのマクロのみです。
これらの特徴から、このフレームワークはどのような環境(プラットフォーム)にも適用可能です。

私も、組み込み開発の単体テストでは、このフレームワークをよく使用します。

2.何が不満?

「min_unit」に対する不満は、下記が挙げられます。

  • 値の比較を行うコードを、自分で書かなければならない
    • 「=」と「==」を書き間違える可能性がある。
      (実際、仕事でやらかしたことがあります。
      このミス見つけたときは、シャレにならないくらい焦りました。)
  • 指定できるメッセージが、テストの出力と期待値が一致しない場合にしか表示されない。
    • テストの出力と期待値が一致した場合も、その旨知りたい!
    • テストの進捗が知りたい!
  • テストの出力と期待値が一致しないと、テストがその場で終了する。
    • 1つ直して再実行して、また別のバグを修正して再実行して…というやり方は効率が悪い。
    • 一通り最後までテストを実施して、NGとなるケースを洗い出したい!
  • メッセージを表示するのに、自分でprintf文を書かなければならない。
    • そこがイイトコロでもあるが、できれば書いてほしい!
  • 実行したテスト、成功したテスト、失敗したテストのそれぞれの件数を教えてほしい。
    • テストの件数の詳細(数)が知りたい!

3.不満を解消

3.1.min_unitの変更

というわけで、上記の不満を解消するべくmin_unitを変更したコードを、下記に示します。

3.2.min_unitからの変更点

min_unitから、以下のような変更を実施しています。

  • mu_assertの引数を増やして、テストの出力と期待値を渡すように変更
  • テストの出力と期待値が一致しない場合、それぞれの値を表示する。
  • テストの出力と期待値が一致した場合でも、メッセージを表示する。
  • mu_run_testの先頭で、テスト開始を示すメッセージを表示する。
  • mu_run_testの完了時に、成功/失敗を示すメッセージを同時に表示する。
  • mu_run_all_test()を新規に追加

一番大きな変更は、mu_assert()マクロのI/Fの変更かと思います。
マクロのI/Fが一部変更になっているので、minunitとは互換性がなくなってしまっています。
それでも、minunit側を少し変更するだけで十分に対応可能な範囲かと思います。
新規に追加した「mu_run_all_test()」マクロについては、実は使用しなくてもテストは実行可能です。
そのため、minunitとの互換性には影響はありません。

4.使ってみました

以下のような簡単な関数の単体テストを、改変/作成したフレームワークを使用して行ってみます。

まず、テストケースを実行する処理の実装です。
実装は、下記のようになります。

前述の通り、mu_assert()の引数を増やし、かつ第1引数には「結果がNGの場合に表示したいメッセージ」ではなく、「確認している内容を示す文字列」を設定しています。
また、main()関数の実装は、下記の通りです。

先頭の3つの変数は、どうしてもここで宣言しなければならない、フレームワーク側で使用する変数の宣言です。
min_unitを使用した場合でも、同様の宣言が必要です。
これらのコードを実装したら、以下のコマンドを実行してビルドとテストの実行を行います。

ビルドとテストの実行は、cygwin上で行っています。
テストを実行すると、コンソールには下図のような表示になります。
test_framework_mid_unit_001_001
うん。
イイ感じです。

5.まとめ

今回、テストフレームワークである「min_unit」を、少しだけですが改変してみました。
結果として、これまで「かゆいところに手が届かない」と思っていたことが解消できました。
ほんの少しでも良いので、単体テストをやりやすくすることに貢献できていれば幸いです。

ではっ!

ex.公開しています

今回作成したフレームワークですが、エントリのタイトルにもあるように「middle_unit」と名付けました。
GitHubにて公開しています。
参考にしていただけたら、嬉しいです。
「いいね!」していただけたら、もっと嬉しいです。

関連記事

source_trail_eye_catch

Sourcetrailを試してみました(2)-Eclipseと連携

どもです。 前回のエントリで、ソースコードを解析するオープンソース「Sourcetrail」を紹介

記事を読む

no image

C言語でEV3開発(10)-opOUTPUT_CLEAR_COUNTコマンド

どもです。 前回のエントリーのラストで、「モーターを動かすコマンド」と書きましたが、今回紹介するコ

記事を読む

eclipse_4.3_kepler

eclipse/CDTにおけるgdbでのデバッグ中に発生するpythonのエラー

どもです。 今回のエントリーは、Eclipse上でのデバッグの際に「pythonのエンコードエラー

記事を読む

no image

Objective-CからC++コードを呼び出す

どもどもです。 今回は、突然ながらMacに関係する投稿です。 ソフト関係のことを勉強していて

記事を読む

toppers

C言語でEV3開発(25)-Q_Learningを実装してみた…が!?

どもです。 今回の内容は、「失敗しました」という内容です。 最近、流行になっている深層学習/

記事を読む

google_test

C言語でEV3開発(6)

どもです。 今回のエントリーは、前回のエントリーの続き、google testでの単体テスト環境に

記事を読む

raspberry-pi

QtでRaspberryPi/GUI開発(1):ためしに時計を作ってみた

どもです。 また更新の間隔が空いてしまいました。 久しぶりの更新です。 前回のエントリーで

記事を読む

iot_at_home_eye_catch

IoT開発(1)-ESP-WROOM-02のセットアップ

どもです。 前回までのエントリで、「DHT11の測定結果をクラウドで見える化する」という内容を書い

記事を読む

raspberry-pi

RaspberryPiで物体検出(2)-白線検出への挑戦(2):輪郭検出による白線検出(実機編)

どもです。 今回は、前回に引き続きOpenCvを用いて道路の白線検出について、です。 1.今

記事を読む

GitHub

Windowsでのカバレッジ測定-OpenCppCoverageを使ってみた(2)

どもです。 前回のエントリーで、OpenCppCoverageというカバレッジを測定する、フリーの

記事を読む

Message

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA


次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

arduino_relay_switch_002_ae_g5v_drv_eye_catch
Arduinoでリレースイッチ(2)-AE-G5V-DRV

どもです。 前回の記事では、「フォトカプラリレー」を使用したLチ

tlp222af_001_eye_catch
Arduinoでリレースイッチ(1)-TLP222AF

どもです。 つい先日、やっとのことでリレースイッチを手に入れるこ

c_sharp_eye_catch
外部からMariaDbにアクセスする(2)-C#からMariaDbにアクセスする。

どもです。 前回のエントリで、外部からMariaDbにアクセスす

c_sharp_eye_catch
外部からMariaDbにアクセスする(1)-データベースの設定

どもです。 今回は、Linux上のMariaDbにWindows

think_about_utest
middle_unit
最小…よりも(ほんの)少し大きいテストフレームワーク

どもです。 今回は、単体テストのフレームワークについて書きます。

→もっと見る

PAGE TOP ↑