ユニットテストを考える

ユニットテストを書きたい。引き継いだプロジェクトに動くユニットテストがないことはよくあることだ。テストが書きやすい設計になっていないからテストを書くのも難しい。

テストはコードを読めばわかるから不要なのではない。コードをいじったときにどこに影響が出るのかを知るための対策だ。引き継いだ直後はソースコードをいじるのが辛い。

ユニットのテストは難しい。ユニットは別の状態・モジュールに依存しており、その何かがきちんと動作することが前提になっている。この問題を解決するのがスタブ・モックらしい。

組込みソフトウェアは制約が多く、ユニットテストも満足に実行できないことが多い。スタブ、モックの重要性は高い。また組み込みソフトウェアのユニットテストはホストPCの上で実行するのがいいと考えている。そのためにはハードウェア依存部とは完全に分離しなければならないし、RTOSやシステムコールも分離しないといけないような気がする。

https://dzone.com/articles/unit-testing-the-myth-of-complete-isolation

気になるタイトルの記事を見つけた。complete isolationはmyth(神話/実際に存在しえない話)なのだろうか。

結論として、この作者の考えるcomplete isolationとは次のことであった。

Unfortunately, when most people first brain-parse the phrase “unit tests are performed in isolation,” they understand it as “complete isolation,” i.e. we should isolate the unit from EVERYTHING.

ユニットはクラス単位とは限らない。何かを集約したものだったり、機能・ビジネスロジックを表現する構成単位をユニットとみなす、ということだろうか。そういうことなら知っていた。

記事の例では「注文クラス」が「アイテム」のリストを持っている。注文の総額を求める関数は、アイテムの金額と個数の和を求めるものだ。この関数をテストするためにアイテムのモックを作成したものを作成している。

OrderItem item = mock(OrderItem.class);
when(item.getPrice()).thenReturn(BigDecimal.valueOf(price));
when(item.getQuantity()).thenReturn(BigDecimal.valueOf(quantity));

このテストコードでモックを作る人は普通はいないと信じたい。でもテストコードもそれなりに設計能力を要するので、下手な人がテストコードを書くとこうなる可能性はある。モックオブジェクトを作るのは面倒だし、モックを作るコストがモックを作るメリットを上回るべきではない。モッキングフレームワークはなんでもできてしまう強力なツールだから、使い方を誤るとおかしなことになる。

コメントの次の指摘は正しい。

"The actual problem here is coupling between the test code and the production code. The more your tests know about the inner details of your production code, the more these two are coupled together, and so the bigger the chance that changing the latter will break the former."

タイトルが気になったので読んだものの肩透かしだった。

もう遅いので寝る。

メモ

  • toriaezunomemo
  • freertos
    • SVCallHandler
    • PendSVHandler
    • SysTickHandler
  • unit-testing-a-project-that-uses-an-rtos
  • セマフォコール:テストできない
  • struct = {} as init in C
  • typedef in func
  • ヒープ禁止
    • スタックに確保
    • モジュール変数
      • スケールしない
      • 使いまわす戦略もあり。
  • VPN/IPSec
  • Hardware Controlling Levels
    • Simple Functional Unit
    • A unit with Preconditions
    • A unit with exclusive state
  • Hardware Simulator
    1. A simulator responds an fake response, sometimes useless
    2. A simulator manages its state, updates it when an event is fired.
    3. A simulator manages its state, updates it actively by itself.