少しパラドックスがあります。
実装を構築する前に、TDD を使用してパスワード ハッシュ メソッドのテストを構築しようとしています。しかし、最初に実装を構築せずに、期待値を事前に考え出す方法はありません。
もちろん、単純なハッシュの実装では、既知のパスワード/ソルトに基づいて期待値を作成するサイトをおそらく見つけることができます。
解決策は、TDD の例外を作成し、最初にテストを作成するのをやめることだと思います。むしろ、実装を構築して適切なソルト/ハッシュ値を見つけ出し、それらの値に対してテストを構築して回帰を防ぎます。
しかし、私が考えていない解決策があるかどうかを確認するためにこれを投稿すると思いました。
または、最初にテストを構築するために頭の中でハッシュを生成できる人がいるかもしれません。
sha-1のような独自のハッシュ関数を書いているのか（この場合はやらないでください）、外部ハッシュとランダム関数を使用してsaltなどを生成しているかどうかはわかりません。あなたの出力を知る必要があります。ハッシュ プロバイダーとランダム プロバイダーをモックして、それらが入力または部分的な結果で呼び出されているかどうかを確認するだけです。
したがって、基本的にTDDを行っているときは、「期待される」出力を知っている必要があります。あなたの場合、予想される出力はハッシュ関数の結果です。
既知のハッシュ アルゴリズムを実装している場合は、サイトからテスト結果を取得したり、手動で生成したりすることは問題ありません。
独自のアルゴリズムを開発している場合。また、アルゴリズム実装のプロトタイプを実装することで、期待される出力もおそらく知っているはずです。それらが正しいかどうかわからなくても、正しいと仮定してテストで値を使用するだけです。ハッシュ関数の実装が変更された場合、それらのテストは赤くなります。