今日の午後、このような状況に出くわしたので、皆さんは何をしているのか聞いてみようと思いました.
ユーザーのパスワードをリセットするためのランダム化されたパスワード ジェネレーターがあり、その問題を修正しながら、ルーチンを (ゆっくりと成長している) テスト ハーネスに移動することにしました。
生成されたパスワードが設定したルールに準拠していることをテストしたいのですが、もちろん、関数の結果はランダム化されます (または、疑似ランダム化されます)。
単体テストでは何をしますか？たくさんのパスワードを生成し、それらがすべてパスすることを確認して、それで十分だと考えますか?
単体テストは、実行するたびに同じことを行う必要があります。そうしないと、単体テストがたまにしか失敗しない状況に遭遇する可能性があり、デバッグが非常に困難になる可能性があります。
疑似ランダマイザーに毎回同じシードをシードしてみてください (テストでは、つまり、製品コードではありません)。そうすれば、テストは毎回同じ入力セットを生成します。
シードを制御できず、テストしている関数がランダム化されるのを防ぐ方法がない場合は、予測不可能な単体テストで立ち往生していると思います。:(
この関数は、すべての入力に対して、出力が仕様に準拠しているという仮説です。単体テストは、その仮説を反証する試みです。そうです、この場合にできる最善のことは、大量の出力を生成することです。それらがすべて仕様に合格した場合、関数が仕様どおりに機能することを合理的に確信できます。
乱数ジェネレーターをこの関数の外に置き、それに乱数を渡して、乱数ジェネレーターに直接アクセスさせるのではなく、関数を決定論的にすることを検討してください。このようにして、テスト ハーネスで多数のランダムな入力を生成し、それらすべてを関数に渡し、出力をテストできます。いずれかが失敗した場合は、その値を記録して、文書化されたテスト ケースを作成します。
いくつかをテストして合格することを確認することに加えて、ルールに違反するパスワードが失敗することを確認するテストを作成します。
生成されたパスワードをチェックして、パスワードが十分にランダムであることを確認するコードベースはありますか? そうでない場合は、生成されたパスワードをチェックするロジックを作成し、それをテストしてから、ランダムパスワードジェネレーターが機能していると述べることができます (「悪い」パスワードは出てこないため)。
そのロジックを取得したら、大量のパスワードを生成してロジックを通過させる統合タイプのテストを記述できる可能性があります。その時点で、ランダムなパスワード生成がどれほど「優れている」かがわかります。
Either use fixed random seed or make it reproducible (i.e.: derive from the current day)
ルールが何であるかを確実に言うのは難しいですが、「パスワードは少なくとも8文字で、大文字、小文字、数字、特殊文字が1つずつ必要です」のようなものであると仮定すると、アルゴリズムが正しいことを証明するために生成されたパスワードの十分な量をブルートフォースでチェックしても不可能です（使用するために指定した特殊文字の数に応じて、8 ^ 70 = 1.63x10 ^ 63以上のチェックが必要になるため、非常に時間がかかります、完了するまでに非常に長い時間がかかります）。
最終的にできることは、実行可能な限り多くのパスワードをテストすることだけです。ルールに違反している場合は、アルゴリズムが正しくないことがわかります。おそらく最善の方法は、一晩実行したままにすることです。朝にすべてが順調であれば、大丈夫である可能性があります。
本番環境で二重に確認したい場合は、パスワード生成関数をループで呼び出し、ルールと照合する外部関数を実装します。失敗した場合は、これを示すエラーをログに記録し（修正する必要があることがわかります）、別のパスワードを生成します。ルールを満たすものが得られるまで続けます。
ユーザーが入力したパスワードは、ランダムに生成されたものと同じ制限に準拠していると想定しています。したがって、既知の条件をチェックするための一連の静的パスワードが必要になる場合があります。その後、動的パスワード チェックを行うループが作成されます。ループのサイズはそれほど重要ではありませんが、ジェネレーターから温かみのあるファジーな感覚を得るのに十分な大きさである必要がありますが、テストの実行に永遠にかかるほど大きくはなりません。時間の経過とともに何か問題が発生した場合は、それらのケースを静的リストに追加できます。
ただし、長い目で見れば、脆弱なパスワードによってプログラムが壊れることはなく、パスワードのセキュリティはユーザーの手に委ねられます。したがって、動的な生成と強度チェックがシステムを壊さないようにすることが優先されます。
私の謙虚な意見では、時々合格し、時々失敗するテストは必要ありません。この種のテストは単体テストではないと考える人もいるかもしれません。しかし、主な考え方は、緑色のバーが表示されたときに機能が正常であることを確認することです.
この原則を念頭に置いて、妥当な回数だけ実行してみてください。そうすれば、誤正解の可能性はほぼゼロになります。ただし、テストの単一の失敗は、失敗のデバッグとは別に、より広範なテストを行うことを余儀なくされます。
まあ、それらがランダムであることを考えると、実際に確認する方法はありませんが、100 000 パスワードをテストすることで、ほとんどの疑問が解消されるはずです:)
非ランダムな結果を取得してそれらの結果をテストするために、乱数ジェネレーターに定数値をシードすることができます。