テスト駆動開発によるステートマシンの開発

ステートマシンモデルは組み込みシステムで広く使用されているため、この記事では、テスト駆動開発（TDD）アプローチの下でステートマシン（SM）ソフトウェアを開発するためのいくつかの戦略について説明します。この出版物は、基本的なステートマシンの概念とTDD技術を説明することから始まります。最後に、TDDアプローチを使用してCで記述されたステートマシンソフトウェアを開発するための簡単で順序付けられた方法を紹介します。

SMモデルは、状態、遷移、およびアクションで構成されます。状態はシステムまたは要素の状態ですが、遷移はある状態から別の状態へのパスであり、通常、先行（ソース）状態を後続（ターゲット）状態に接続する対象のイベントによって開始されます。要素によって実行される実際の動作は、アクションで表されます。

UMLステートマシンでは、アクションは、状態へのエントリ、状態からの終了、遷移自体、または「内部遷移」または「反応」と呼ばれるものに関連付けることができます。すべてのステートマシンの形式（UMLステートマシンを含む）は、ステートマシンが次のイベントの処理を開始する前に、各イベントの処理を完了することを普遍的に想定しています。この実行モデルは、Run To Completion（RTC）と呼ばれます。このモデルでは、アクションに時間がかかる場合がありますが、保留中のイベントは、ステートマシンが完了するまで待機する必要があります。これには、終了アクション全体、遷移アクション、および開始アクションシーケンスがこの順序で含まれます。

TDDを使用してステートマシンを開発する戦略を扱う前に、その定義、重要性、およびアプリケーションについて言及する価値があります。

まず第一に、TDDはソフトウェアを段階的に構築するための手法です。簡単に言えば、最初に失敗した単体テストを作成しない限り、製品コードは作成されません。テストは小規模です。テストは自動化されています。テスト駆動は論理的です。つまり、本番コードに飛び込む代わりに（後でテストを残す）、TDDプラクティショナーはテストでコードの望ましい動作を表現します。テストが失敗すると、TDDの実践者がコードを記述し、テストに合格します。 TDDプロセスの中核には、「TDDマイクロサイクル」と呼ばれる短いステップで構成される繰り返しサイクルがあります。

次のリストのTDDサイクルの手順は、JamesGrenningの「埋め込みCのテスト駆動開発」の本に基づいています。

• 小さなテストを追加します。
• すべてのテストを実行します。新しいテストが失敗すると、コンパイルすらできない場合があります。
• テストに合格するために必要な小さな変更を加えます。
• すべてのテストを実行し、新しいテストに合格するかどうかを証明します。
• リファクタリングして重複を取り除き、表現力を向上させます。

図1の図を使用して、TDDを使用してステートマシンを開発する簡単な方法を見つけましょう。ステートマシンが初期化されると、 StateA から開始されます 州。 アルファを受け取ったら イベントの場合、ステートマシンは StateB に移行します xStateA（）、effect（）、nStateB（）アクションをこの順序で実行して状態を確認します。では、図1のSMをテストして、適切に動作するかどうかを判断するにはどうすればよいでしょうか。

図1.基本的なステートマシン（出典：VortexMakes）

図1のようなSMをテストする最も伝統的で最も簡単な方法は、主にSMUT（テスト対象のステートマシン）の状態遷移表を検証することです。これにより、州ごとのテストケースになります 、SMUTは対象のイベントによって刺激され、どの遷移がトリガーされるかを確認します。同時に、これは、実行された遷移ごとにターゲット状態と実行されたアクションをチェックすることを意味します。アクションが十分に複雑な場合は、そのための特定のテストケースを作成する方が適切です。 （単体テストを使用したステートマシンのテストの記事では、この戦略について詳しく説明しています。）

すべてのテストケースは、xUnitパターンに従って4つの異なるフェーズに分割されます。

• セットアップ SMの現在の状態（ StateA ）などのテストの前提条件を確立します ）、処理されるイベント（ Alpha ）、および遷移ターゲット状態（ StateB ）である期待されるテスト結果 ）および実行されるアクションのソートされたリスト（xStateA（）、effect（）およびnStateB（））。
• 演習 アルファでステートマシンを刺激します イベント。
• 確認 得られた結果をチェックします。
• クリーンアップ テスト中のステートマシンをテスト後の初期状態に戻します。オプションです。

上記の戦略は、TDDを使用してSMを開発するのに十分です。ただし、場合によっては、機能をチェックするために複数の遷移が必要になります。これは、後続の遷移の一連のアクションによってのみ効果が表示されるためです。つまり、機能には、SMUTの一連の状態、イベント、および遷移が含まれます。このような場合、孤立した状態遷移よりも完全で機能的なシナリオをテストする方が適切です。その結果、テストケースは、前述の戦略よりも機能的で抽象的ではありません。

図2のステートマシンを使用して、この概念を調べてみましょう。

図2.DoWhileステートマシン（出典：VortexMakes）

図2は、DoWhileと呼ばれるステートマシンを示しています。これは、「do-while」ループに似た実行ループをモデル化しています。 DoWhileは、Yakinduステートチャートツールを使用して描画されました。 「x =0」および「output =0」アクションは、DoWhileが作成されるときに呼び出され、これらのアクションは、すべてのDoWhileの属性のデフォルト値を設定します。ループの反復回数は、「x ++」または「x =（x> 0）？」で設定する必要があります。 x–：xのアクション。 「i =0」アクションは、ループの初期条件を確立します。ループ本体は、ループの反復を維持する「i ++」アクションによって実行され、終了条件は、「i ==x」ガードを介した選択疑似状態によって評価されます。 trueの場合、ループ本体が再度評価されます。終了条件がfalseになると、ループは「output =i」アクションの実行を終了します。

新しい機能を開発する前に、テストリストを作成すると便利です。テストリストは仕様から導き出され、それが何をすべきかについての最良のビジョンを定義します。完全である必要はないため、前者のリストは、後で変更できる一時的なドキュメントにすぎません。 DoWhileの初期テストリストを以下に示します。

• すべてのデータは、SMが初期化された後にデフォルトで設定されます
• X属性をインクリメント
• X属性をデクリメントします
• 単一の反復ループを実行できます
• 複数の反復ループを実行できます
• 非反復ループを実行できます
• 範囲外の値を確認する

DoWhileステートマシンを開発するために、CeedlingとUnityは、最も単純ですが明快なプログラミング手法である「switch-case」文の使用とともに使用されます。 Ceedlingは、Cプロジェクトのテストおよびビルド環境全体を生成するためのビルドシステムです。 Unityは、Cプロジェクト用の軽量でポータブルな表現力豊かなC言語テストハーネスです。

このステートマシンを表す2つのファイル、DoWhile.hとDoWhile.cは、テスト対象のソースコードです。コードリスト1は、test_DoWhile.cファイルのフラグメントを示しています。これは、前述の戦略を適用することにより、上記のテストリストを実装します。この記事を単純にするために、コードリスト1はテストケースのみを示しています。「単一の反復ループを実行できます」。これはtest_SingleIteration（）によって実装されます。コードとモデルの両方がhttps://github.com/leanfrancucci/sm-tdd.gitリポジトリで入手できます。

コードリスト1：単一反復テスト（出典：VortexMakes）

このテストは、DoWhileが1回の反復のみを正しく実行できることを確認します。これを行うには、test_SingleIteration（）は、DoWhile_init（）を呼び出してDoWhileステートマシンを初期化します（96行目）。 DoWhileループによって実行されるゼロの反復回数を設定します。その後、DoWhileはDoWhile_dispatch（）を呼び出してイベントを処理する準備が整います。単一の反復を実行するために、test_SingleIteration（）は Up を送信します DoWhileへのイベント（97行目）。このイベントは、反復回数を1に増やします。テストは、開始を送信してループを開始します イベント（行98）、次にアルファを送信します イベントなので、DoWhileは単一の反復を実行します（99行目）。これは、out属性の値が実行された反復の数と等しいことを確認することによってチェックされます（行101）。最後に、DoWhileは StateC にとどまる必要があります 状態（102行目）。

DoWhileが複数の反復を実行できることを証明するために、コードリスト2に示すようにtest_SingleIteration（）が拡張されています。

コードリスト2：複数の反復テスト（出典：VortexMakes）

コードリスト3に示されているtest_NoneIteration（）テストは、 Alpha を受け取ったときにDoWhileが反復を実行しないことを確認します。 上で反復回数を事前に設定せずにイベント イベント。

コードリスト3：非反復テスト（出典：VortexMakes）

DoWhileの実装の詳細はこの記事の目的ではありませんが、コードリスト4とコードリスト5は、DoWhile.cファイルとDoWhile.hファイルの一部を示しています。これらのファイルは、実際には、Cで「switch-case」文を使用したDoWhileの実証的な実装を表しています。

コードリスト4：DoWhile実装のフラグメント（出典：VortexMakes）

コードリスト5：DoWhile仕様のフラグメント（出典：VortexMakes）

上記で紹介した両方の戦略は、TDDを使用してステートマシンソフトウェアを開発するためのシンプルで順序付けられた方法を提供します。これは、ソフトウェア品質を向上させるための最も重要なアプローチの1つです。

最初の戦略は、主にSMUTの状態遷移表を検証することで構成されます。この方法では、州ごとのテストケースが作成されます 。もう1つの戦略は、完全で機能的なシナリオのテストケースを実現することを提案しています。 、SMUTの一連の状態、イベント、およびアクションが頻繁に含まれます。この2番目の戦略により、テストは最初の戦略よりも機能的で抽象度が低くなります。これらの戦略は、特定の種類のシステム、プログラミング言語、またはツールに依存しませんが、組み込みシステムで非常に役立ちます。これらの戦略の多くは、通常1つ以上のステートマシンで定義されるステートベースの動作を備えているためです。

C言語が選択されたのは、組み込みソフトウェア開発で最も人気のある言語の1つだからです。そのため、その言語でTDDを適用するために、CeedlingとUnityが選択されました。結論として、これらの方法により、開発者は、従来のアプローチよりもはるかに柔軟で、保守可能で、再利用可能なソフトウェアを、よりシンプルで順序付けられた方法で構築できます。