ユニットテスト：アセンブラコードとさまざまなアーキテクチャ
現在、一部の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コードを単体テストする（そしてこの場合、「私には不可能」の部分を除外することによってそれを実現します）、または他の形式のテストに依存します。