sioaji2012のブログ

普段は組み込み開発でC言語のみです。主にプログラムや勉強日記です

組込C言語でUnitTest 1

組込開発C言語でテストコード書きたい

普段は、組み込みファーム開発で C言語 しかプログラムしていません。

今のところ、TDD(テスト駆動開発をやりたいわけではありません。
というか出来ないです。。
(やってみたいですが・・・)

私の会社では、シミュレータを自前で開発したり、実行ログの自動解析ツールを開発したりして、 動的なシステムテストが主流になっているので、 テストコードを書くという文化はありませんし、メリットを感じられていない様です。

実際に、『テストコード書ける様に環境を作っていきます!』 と宣言した時も、一部の方から猛反撃をくらいました。

  • ほんとに効果あるの?
  • テストコードを書くにあたっての費用対効果を説明してから
    テストコード書きましょう。って言ってくださいよ!
  • 何か効果あるらしいから、やってみようは拒否する!
  • 効果があるかどうかわからん物の環境構築って、、
    それ自体無駄だからやめた方がいいんじゃないの!

・・・怖っ・・・

一応は、『テストする事についての一般的な考え』を説明してましたが。。。

後工程での不具合だと

  • 原因にたどり着くまで時間がかかる
  • 大昔の実装なので当時の資料を掘り起こす時間ロス
  • システムとして既に作り込まれているので、修正による影響範囲とか確認項目が莫大
  • 市場に不具合が出回る

前工程での不具合になると

逆の事が言える

  • 修正したらすぐテスト失敗を報告してくれるので、原因を教えてくれてるに近い。
  • 実装したばかりなので、誰がいつ何の為に実装した?とか資料集めなどいらない事が多い。
  • 修正による影響範囲とか確認項目は、たぶんさっき修正したのとそんなに変わらない。
  • 市場に不具合が出回る前に見つかった!

継続的インテグレーション

  • 昔書いたテストが不具合を教えてくれる。自分の修正箇所が他の不具合を誘発する事に気がつく。

その他

  • テストしやすいモジュール化された良いコードが出来る。
  • リファクタリングしやすくなる (上記につながる )
  • システムでは発生させるのが難しいパターンを試せる。
  • 不具合の再現確認が出来る。修正の効果確認も同様、
  • なんか、安心だ!(モチベーション大事)

デメリット

  • テストコード書く時間が増える
  • そもそもテストコード書き方の勉強が必要。
  • ハード依存の部分や、システムテストが難しいので出来ない。
  • 仕様変更や不具合修正のたびにテストコードのメンテが必要。
  • テストコード自体の信頼性が気になる(やりたいテスト。目論見のテストをしてくれているのか)

それでもやるしかない

上からおりてきた仕事ですから、やらないという選択肢は簡単ではないですし。

ただ、只今の状況は、『非常にきびしー』です。

理由

  • レガシーコード*1だから。
    テストは当然ないですが、よくわからない関数が多いのでテストが書けない。
    コード流用することは美。リファクタリングするのは悪。で、レガシーコードが蔓延しています。
    (そもそもソース構造をまとめた資料もないし)
  • デメリットをくつがえす実例を示さないといけない。(費用対効果)
    テスト出来るところを見つけて。効果を積み重ねる必要がある。でもそこまでコツコツとやらせてくれるかどうか。・・・というと駄目だろうな。
  • テストの為にオリジナルのソースに手を加えたくない。
    モックが必要になった場合に、オリジナルのソースをいじらずに出来るか。
    C言語の壁が待っていそう。

一応、

選んだツールは、OSSの GoogleTest

本当は、CppUTest が組み込み用で広く使われているので、そちらが良かったかもしれませんが、

選んだ理由の概略は、モックのコード行数が少なく済むみたいなのと、Googleさんも自分たちでつかってるんだろうという事です。


最後は、商用ツール買えば楽にテストコード書けますよ。になるかもしれない。(会社ですし)

会社でやったことは、ここでは書けませんが、

redmineプラグイン開発のお勉強を保留して自分の時間を使ってしまいましたし、

(これはこれでグレーですが・・・。自己啓発ということで。。。)

少し覚え書きな感じになりますが、自宅で検討した内容を、あと少し書き留めていこうと思います。

つづきは、次回へ。


*1:一般的には『理解しづらい・変更しにくいコード』TDD本?では『テストの無いコード』だと思います