アプリケーションの API 部分の BDD にインスパイアされた単体テストをまとめています。(ええ、わかっています。BDD はドメインに関するものであり、スーツと対話することになっていますが、最初はあまり目立たないもので BDD を試してみたいと思います)
通常の使用。 開発者は、通常のパラメーター値で API メソッドを使用します。
極端な使用。開発者は、異常に大きい/小さいパラメーターを使用して API を呼び出します。たとえば、zip() メソッドには 2 GB のファイルが渡されます。
API の乱用。開発者は狂ったパラメーターを使用して API を呼び出します。狂ったプログラマーは日付を整数パラメーターに渡しますよね?-パラメーターは忘れられます。
悪意のあるハッキング。開発者は、API が何を意図しているかは気にしませんが、代わりに、任意のコードを実行する方法を探しています。テストには、JavaScript や SQL を含めて、それらをどこでも実行できるかどうかを確認します。
他に考慮すべきシナリオはありますか?
もちろん、考慮すべきシナリオは常に他にもあります。率直に言って、事実上無限のシナリオのプールがあります。これは非常に自由回答形式の質問です。
悪意のあるハッキングのシナリオに関しては、バッファー オーバーフローの明らかな箇所だけに気を配り、確認済みのセキュリティの脆弱性をテストして、誤ってそれらを再度開くことがないようにする必要があります。また、脆弱性が確認された場合はいつでも、同様のプログラミング手法とパターンを使用しているコード内のすべての場所を探し出し、それらも事前にテスト/修正してください。ただし、多くの場合、ファジングの方が良い結果が得られます。自動化されたテストは、セキュリティの問題に対処する上で重要な部分ですが、ツールボックスの主要なツールであってはなりません。
考慮すべきその他の事項は、データ固有のものである可能性があります。たとえば、日付を解析するときは、2009 年 2 月 29 日や 2009 年 9 月 31 日のようなものを必ず処理してください。可能であれば、1900 年 1 月 1 日と 2038 年 12 月 31 日を処理するようにしてください (ライブラリによっては許可されない場合があります)。
できることの 1 つは、作成しているすべてのライブラリ呼び出しのドキュメントを確認し、どの条件でどの例外がスローされるかを把握し、それらの例外をトリガーする入力を意図的に見つけて、テストがあることを確認することです。これらの例外が処理されていること、またはライブラリ コードの場合は文書化されていることを確認します。
コード カバレッジ ツールとコード ミューテーションは、以前はカバーされていなかったシナリオを特定するのにも役立ちます。