現在、一部のCコードのユニットテストを行っており、問題が発生しています。
コード内には、SPARC 8アーキテクチャ用のインラインアセンブラコードを含む関数と呼ばれます。
私はx86アーキテクチャーで単体テストを行っているため、コンパイルできません。残念ながら、ターゲットプラットフォームでテストすることはできません。
この問題に対する適切なアプローチは何だと思いますか?インラインアセンブラコードを#ifdef UNIT_TEST #endif
で囲んで元のコードを変更する必要がありますか、それとも別の解決策がありますか?
単体テストをすべて同じプラットフォームで実行する必要があると言った人はいませんが、100%のテストカバレッジを達成できるとは誰も言っていません。
最初のステップとして、#ifdef
コードを出力し、できればプラットフォーム固有の関数に分解します。この関数のx86用の適切な実装を記述します。ただし、「単体テスト」または「単体テストではない」に基づいてコンパイルするコードを選択することは適切ではないと思います。むしろ、単にアーキテクチャを使用します:x86またはSPARC。
次に、テストとプログラムの作業を続けます。作成したテストの「穴」を文書化するだけです。x86での単体テストはSPARCでの単体テストではありません。この特定のコードをテストする方法がまだわからないので、進行を止めないでください。
正当な理由(この例では、タイトループで非常に頻繁に使用されるルーチンなど)でこのアセンブラーを作成したと想定すると、不快に感じるはずです。良いニュースは、昨日出荷しない限り、穴をあける時間があるということです。ここにいくつかのアイデアがあります:
1)おそらく、統合テスト(またはフィールドテスト、または単体テストよりも高いレベルのテスト)を実行しています。観察された動作が仕様どおりである場合、アセンブラコードはおそらくで問題ありません。結局のところ、それはすべてテスト条件に関するものです。統合テストにほとんどの運用条件が含まれていれば、問題ありません。確かに、ユニットテストの場合と同じフィードバックは得られません(ループは長くなります。失敗は「これを予期して、それを取得した」ほど正確ではなく、調査が難しくなります)。ただし、コードはテストされます。
2)あなたは周りに何人かの同僚がいて、この特定の部分のコードレビューを喜んで行うでしょう。
3)エミュレーターを使用してみることができます(QEmuはSPARC archsをサポートしているようです)。これで効果が見込めるかどうかはわかりませんが、試してみませんか?
4)ターゲットマシンに手を置くことができないと100%確信していますか?このコードの欠陥にどれくらいの費用がかかりますか?数日以上の作業であれば、おそらくマネージャーに古いSunステーションを購入してテストを実行するように説得できます。テストは常に一見高すぎるように見えますが、それは保険または投資のようなものです。本当に、ハードウェアは工数と比較して安価で、会社の利益を失っています(さらに悪いことに、法廷裁判)。
要約すると、あなたはあなたが感じていると感じますmustコードを単体テストする(そしてこの場合、「私には不可能」の部分を除外することによってそれを実現します)、または他の形式のテストに依存します。