レガシーなプレーンCプロジェクトへの単体テストの追加
タイトルはそれをすべて言います。私の会社では、完全にプレーンCで記述されたマイクロコントローラーデバイス用のレガシーファームウェアプロジェクトを再利用しています。
明らかに間違っていて変更が必要な部分があり、C＃/ TDDのバックグラウンドから来て、機能を変更しないことを保証するためにテストなしでランダムにリファクタリングするアイデアは好きではありません。また、見つけるのが難しいバグは、わずかな変更（回帰テストが使用された場合に修正されると私が信じているもの）を通じて、多くの場合導入されていることを確認しました。これらのミスを回避するために、細心の注意を払う必要があります。コードの周りの多数のグローバルを追跡することは困難です。
要約する：
- リファクタリングの前に、既存の密結合コードに単体テストをどのように追加しますか？
- どのツールがお勧めですか？ （それほど重要ではありませんが、それでも知っておくと便利です）
私はこのコードの記述に直接関与していません（私の責任はさまざまな方法でデバイスとやり取りするアプリです）、それらが使用される可能性がある場合、優れたプログラミング原則が残されていると悪いことになります。
Michael Feathersによる Working Effectively With Legacy Code のコピーを入手してください。このような状況に対処するためのものです。 OO C++やJavaなどの言語に重点を置いていますが、それでもなお多くの助けになると思います。
その一部（または初期のドラフト記事）は無料で入手できるようです ここ 。
テクニックについては、おそらくMichael Feathers bookPéterTörökの回答 はかなり包括的です。この本に行きたくない場合は、3つのステップからなるプロセスをお勧めします。
- テスト不可能なコードを調べ、そのコードの機能の小さな部分をテスト可能な関数に複製します。新しい関数は、複製しようとしている関数と明らかにの振る舞いをすることが重要です-私は実際にユニットテストを書くことを主張していませんレガシーコードの信頼性を維持するために、非常に注意深く、スコープを制限する必要があります。
- これらの新しい関数に関するユニットテストを記述します。
- 元のコードを変更して、新しい関数を呼び出します。
このプロセスを数回繰り返すと、レガシーコードベースの品質が大幅に向上していることがわかります。
ツールに関する限り、C++はCを呼び出すことができるため、C++の単体テストフレームワークを使用してCコードをテストできることに注意してください。たとえば、プロジェクトで一連のCコードを単体テストするために CPPUnit を使用しています。