unit-testing - 単体テスト ビルド ファイル

Question

ビルド ファイルの単体テストに最適なポリシーは何ですか?

質問する理由は、私の会社が信頼性の高い組み込みデバイスを製造しているからです。ソフトウェア パッチは、お客様が配布するのに何千ドルもかかるため、オプションではありません。このため、非常に厳格なコード品質手順 (単体テスト、コード レビュー、トレーサビリティなど) を採用しています。これらの手順はビルド ファイルに適用されています (知っておく必要がある場合は autotools です。残念です) が、ハックのように感じます。

ええと...プロジェクトがコンパイルされます...ビルドファイルをレビュー済みおよびユニットテスト済みとしてマークします。

もっと良い方法があるはずです。アイデア？

Answer 1

これは、12 を超えるプラットフォームにわたって大規模なコード ベース (数百万行のコード) を構築するときに採用したアプローチです。

• Makefile の変更は、ビルド チームによってレビューされます。 これらの人々は、私たちのビルド環境で人々が犯しがちなエラーを知っており、ビルドが壊れたときにその矢面に立たされるのは彼らであるため、問題を見つける意欲があります。
• Makefileに入れる必要があるものを最小限に抑えて、エラーの可能性を減らします。Makefile を生成する make の上にレイヤーがあります。開発者は、タグを使用して、たとえば特定のターゲットが共有ライブラリまたは単体テストであることを上位レベルのファイルで示すだけです。通常、ターゲットは 1 行で定義され、生成された Makefile で複数の設定/ターゲットが生成されます。プラットフォーム固有の詳細などを抽象化してターゲットを非常に単純にすることができるsconsなどのビルド ツールを使用して、同様のことを行うことができます。
• ビルドツールの単体テスト。 このツールは Perl で書かれているので、そこで Perl のTest::Moreユニット テスト フレームワークを使用して、ツールが上位レベルのファイルを指定して正しい Makefile を生成することを確認します。代わりに scons のようなものを使用する場合は、それらのテスト フレームワークを使用します。
• 毎晩のビルド/テスト スクリプトの単体テスト。 各プラットフォームでナイトリー ビルドを開始し、静的分析ツールを実行し、単体テストを実行し、機能テストを実行し、すべての結果を中央データベースに報告する一連のスクリプトがあります。主に sh/bash/ksh/etcのshunit2単体テスト フレームワークを使用して、さまざまなスクリプトを個別にテストします。
• ビルド/テスト プロセスのエンド ツー エンド テスト。 後者はビルドに何時間もかかる可能性があるため、本番コードではなく小さなソース ツリーで動作するエンド ツー エンド テストに取り組んでいます。これらのテストは主に、コード カバレッジ ツールをアップグレードしたり、ビルド スクリプトを変更したりした後でも、ビルド ターゲットが引き続き機能し、結果を中央データベースに報告することを確認することを目的としています。

Answer 2

ビルドファイルを使用して、既知のバージョンのソフトウェア（またはビルドの観点から類似したより単純なコード）をコンパイルし、新しいビルドツールで得られた結果を期待される結果（ビルドツールの検証済みバージョンでビルドされたもの）と比較します）。

Answer 3

私のプロジェクトでは、ビルド ファイルはあまり変更されません。さらに、いくつかの変数を変更するだけで、以前のプロジェクトのビルド ファイルを再利用できます (わかりやすいセクションに移動しました)。そのため、ビルド ファイルを単体テストする必要はありません。これは、他のプロジェクトでは異なる場合があります。