連続記事#5 テスト駆動開発 はじめの一歩

背景・目的

自社向けの勉強会でなにかテーマを決めて、ソフトウェア開発の上流工程から下流工程まで説明する連続講座を開催し、自分のスキルアップしたいと考えました。
講座参加者に学びになれば尚良、と考えました。この記事は講座資料を再掲・補足説明する位置づけにしたいと考えています。

現在予定している講座はつぎのとおりです。

• 連載記事 #1: 要求の理解　
• 連載記事 #2: 要求を仕様化する
• 連載記事 #3: 設計(概要設計)
• 連載記事 #4: 設計(詳細設計)
• 連載記事 #5: TDD　#1 はじめの一歩 ★いまここ
• 連載記事 #6: TDD　#2 LEDドライバ(ホストPC編)
• 連載記事 #7: TDD　#3 LEDドライバ(ターゲット編) 　

今回の講座の資料はこちらにアップロードしました。

組み込みソフトウェア基礎_【連続講座 #5】テスト駆動開発 はじめの一歩

前回は概要設計から詳細設計を行うというタイトルで詳細設計について書きました。
今回はTDDについて書きます。

テーマについて

テーマは既存組込み製品(CQ EVカート)のマイコンを変更すると決めました。
テーマ設定理由、EVカートについての説明は連載記事#2　要求を仕様化するのこちらのリンクを参照ください。

テスト駆動開発とは?

文字とおりテストでソフトウェア開発を駆動していきます。
テストが開発の起点となります。
実装→テストではなく、テスト→実装の順番で開発を進めます。

【テスト駆動】してどうする?ですがテストを書いてより良い設計を導くことがTDDの目指すところだと思います。

テスト駆動開発をやるモチベーション

TDDで次の効果・効用が期待できるかなと考えています。

• デグレードが少なくなる。
• リファクタリングでコードが綺麗になる。
• 開発者の不安が少なくなる(なくなりはしないと思う)。

【組込み】でテスト駆動開発をやるモチベーション

• ハードウェアがなくてもテストができる(手法がある)。
• ハードウェア・ソフトウェアの不具合要因切り分けが明確になる。
• ターゲットマイコンの開発環境起因(ターゲットのライブラリにバグがあるなど)の切り分けが可能になる。

私がTDDを学びはじめた動機

組込み製品の派生開発（既存機種のバージョンアップ）でデグレードが多く発生しました。
既存機能が正しく動くことを保証しながらも新機能を組み込む技術・ノウハウを学びたいと思いました。
TDDはこの課題を解決するヒントになるのでは?、と思ったことがきっかけです。

私がTDDを学んだ感想

• 素直に楽しい。
• TDDのサイクル(レッド→グリーン→リファクタリング)を回すのが楽しい。
• テストを書いてテストが成功したときの快感。
• 安心できる。
• コードが成長していく実感が得られる。
• コードが綺麗に保たれている実感がある。

組込みでTDDを推進していくうえでの課題

• TDD開始前の戦略立案(どこまでTDDを使い、どこからが実機確認なのか、その線引き)
• テストが難しい領域(例. 組込み装置の画面系)でのTDD活用
• 良い設計を導くためのTDD活用

現状はテストフレームワークを使いテストを書き、TDDのサイクルを回せるようになったという状況です。
TDDを使った良い設計の例はTDD学習の参考 4, 5が参考になります。

環境構築

テストフレームワークの選択

組込みソフトウェアで使うことが多いC, C++で代表的なテストフレームワークはつぎになるかと思います。

• Unity
• CppUTest
• Google Test

TDD学習の参考 1の本で多く説明されている・マイコンにも組込み可能なテストフレームワークのCppUTestとしました。
ホスト環境でのみTDDするの場合だったらGoogle Test推しの声が多い気がします。

ターゲットマイコンの選定

TDDの学習をするにあたり、ホストPC&マイコンターゲットでもTDDをしてみたいと漠然と考えていました。
今回はSTマイクロエレクトロニクスのSTM32マイコンボード【NUCLEO-F446RE】に決めました。
以下、マイコンのリソースです。

• STM32F446RET6 64ピン
• Arm Cortex-M4コア 180MHz
• フラッシュ: 512Kbyte
• SRAM: 128Kbyte
• Arm Mbed対応

ターゲットマイコンの選定理由

連載のテーマ【既存組込み製品(CQ EVカート)のマイコンを移植する】ではカートのモーター制御をおこないます。
該当マイコンボードに搭載されているマイコンはモーター制御用のタイマー機能を持っていたことがわかったのが理由です。
また個人的に他のSTM32マイコンボードより多く使ったことがあり慣れていたことも理由です。

テストを書いてみる

TDDのステップ

TDDはつぎの流れで進めます。この流れを意識します。

• テストを書く。
• テスト失敗を確認する(レッド)。
• テスト成功させるためのプロダクトコードを書く。
• テスト成功を確認する(グリーン)。
• テスト成功したままソースコードを綺麗する(リファクタリング)

TDDサイクルを回してみるデモ

TDD学習の参考 1の写経を行いTDDを学ぶことにしました。
本と一緒にこちらのリポジトリのブランチのコミットログを追っていただくとTDDの進め方がなんとなくわかると思います。
コミットログはTDDのステップの段階ごとにコミットしていくように意識しました。

ターゲットボードでTDDしてみた話

前に書いたLEDドライバはホストPCでTDDをやっています。
ターゲットボードでもTDDしてみたかったのでやってみました。

こちらの記事で紹介しています。
STM32CubeIDEにCppUTestを環境構築し、STM32マイコンでTDDする

結果、ターゲットボードでも簡単な例ですがTDDすることができました。
ただCppUTestのメモリ使用量が該当ターゲットボードのRAMサイズを圧迫しているのでメモリサイズを削減する調整・設定を行う必要があると考えています。

TDD学習の参考

　1.　テスト駆動開発による組み込みプログラミング
　2. ［動画で解説］和田卓人の“テスト駆動開発”講座 記事一覧
　3. 『テスト駆動開発による組み込みプログラミング』を読んで学んだこと
　4. TDDによるマイコンのLチカ開発(1)
　5. TDDによるマイコンのLチカ開発(2)(完)

次回予定

テスト駆動開発 はじめの一歩は如何でしたでしょうか?
なにかお役にたてると嬉しいです。
よければ感想などをコメントくださるとありがたく、猫のように喜びます。

次回の自社向け勉強会は10/31(月)で開催予定です。その頃にまた勉強会の内容を記事化したいと考えています。
勉強会の内容はつぎを考えています。

【連続講座 #6】TDD #2 LEDドライバ(ホストPC編)

組込みソフトウェア開発はクロスプラットフォーム開発(開発するPCと組込み装置が実行する環境が異なる)が多いと思います。
例えば、開発PCはWindowsで組込み装置が実行する環境はOSなし、などの環境です。
まずは開発PC(ホストPC)でTDDしたいと思います。

最後まで長文を読んでいただきありがとうございました。次回もよろしくおねがいします。