この質問が似ていることを序文にしたいと思いますが、私の質問にはランダム性は関係せず、単なる決定的な決定論なので、「既知のシードを使用する」という答えは実際には当てはまりません。同様に、この質問は似ていますが、再び、アルゴリズムが失敗することを期待していません-どの方法が正しいかわかりません。
この質問は、グラフアルゴリズムのテスト中に発生しました。しかし、決してそれらに限定されません。A *などの一部のアルゴリズムには、複数の正解があります。正確な実装に応じて、いくつかの回答のいずれかが得られる場合がありますが、それぞれが同じように正しいです。ただし、どちらを先に吐き出すのかわからないため、テストを難しくする可能性があります。また、回答を手作業で計算するのは非常に時間がかかります。
私の特定のケースでは、Floyd-Warshallを修正して可能な限りすべての最短経路を吐き出すことで回避し、それを手作業でテストしました。それ自体が優れた機能であるという利点がありました。次に、FWからの既知の正しいパスに関して他の機能をテストできます（返されたパスが、その開始/終了ペアに対してFWによって返されたパスのいずれかである場合、それは正しいです）。もちろん、これは、FWの動作方法が原因で、密なグラフでのみ機能しますが、それでも優れています。
ただし、この特性を備えたすべてのアルゴリズムで常に実行できるとは限りません。これまでのところ、私が思いついた最良の答えは、正解そのものではなく、正解の特性をテストすることです。最短パスアルゴリズムに戻るには、返されたパスのコストを既知の正しいコストと比較し、パスが有効であることを確認できます。
これは機能しますが、特に検証自体が複雑な場合（たとえば、正しいアルゴリズムが存在する場合、最小スパニングツリーの検証は既知の難しい問題であり、おそらく以下よりも難しい場合）、すべてが正しく検証されないというリスクがありますMST自体の構築）、この場合、テストコードを広範囲にテストする必要があります。さらに悪いことには、MST検証アルゴリズムをテストするためにMSTを構築する必要があるため、MSTテストがMST検証アルゴリズムの動作に依存し、MST検証アルゴリズムのテストがMST生成コードの動作に依存するという素晴らしいシナリオになります。
最後に、出力を観察し、手作業で検証し、検証したばかりの出力をテストするためにテストをハードコーディングする「簡単な方法」がありますが、毎回テストを修正する必要があるため、それは素晴らしいアイデアではありません実装を少し変更します（これは自動テストで回避することになっています）。
明らかに、答えはある程度テストしている正確なアルゴリズムに依存しますが、いくつかの明確で決定的な「正しい」出力を持つアルゴリズムを検証するための「ベストプラクティス」があるかどうか疑問に思っていましたが、それらの正確な正しい出力は事前に知っていて、事実を確認することすら難しいかもしれません。