私はある種のテスト機能や契約を検討すべきかどうかについて疑問を抱いています。契約のすべての列挙値をテストすべきですか？
の私は、入力として、{オブジェクト」 『myObjectというを』}受け入れ/ getToolTypeようなAPI、およびフォーム{タイプ： 『[AZ] +』}内のタイプに戻り持っていると言うそれがあった
を返される型が文字列のセットと一致するとクライアントとサーバーの間で合意されたので、[hammer | knife | screwdriver]としましょう。返された型が不明な場合、フォールバック値を使用して解析することを決定しました。
消費者は、/ getToolTypeが呼び出されたときに小文字の文字列 "hammer"が返されるように、プロデューサが引き続き一致するように各タイプ（ハンマー、ナイフ、スクリュードライバ）のテストケースを含める必要があります。ハンマーobj ect？ または、このようなテストケースを機能的と見なしますか？なぜ？
大きな質問です。短い答え：右か間違った方法はありません、あなたがそれをやりたいだけです。
長い答えは：
協定（契約検査）のポイント特定のシナリオをテストし、それらが一致することを確認することです。あなたの契約では、正規表現を作成してその列挙型の文字列型を許可することもできますし、nullでもかまいませんが、消費者が単にその値を気にしない場合にのみ可能です。たとえば、ツールタイプにブランドがある場合は、ブランドについては気にしません。ただ、消費者にブランドを表現するだけなので、文字列として返されます（フロントエンド）。
しかし、私があなたのシナリオを理解しているとすれば、ツールタイプが実際にはそれが当たるエンドポイントを考えるとかなり重要だと思われます。したがって、私はおそらく特定のテストと契約を各enumに対して消費者の特定のシナリオが有効であることを確認してください（私は何かをXと呼びますが、YはツールタイプZを持つことを期待しています）。
これらのソリューションはどちらも有効ですが、これは次のとおりです。特定のツールタイプが消費者にとって重要だと思いますか？そうであれば、それに特有の契約を作成し、そうでなければ汎用契約を作成します。
希望に役立ちます。
IMO短い答えは「いいえ」です。
契約テストは構造体の方がより関心があります。境界テストを開始すると、機能テスト[1]領域に移動します。これはプロバイダコードベースで最適です。マッチャを使用して、これらの3つの値の1つだけが返されるようにすることができます。これにより、プロバイダのビルドが他の値を返すことができなくなります。
私は@ J_A_Xのコメントをエコーします。正しいか間違った答えはありません。すべての入出力データの順列を注意してください。
[1] https://docs.pact.io/best_practices/contract_tests_not_functional_tests.html