単体テストをすべきか

私のWebサービスのロジックのほとんどは、サプライヤーのWebサービスとの対話（可用性の確認、注文など）を含みます。それらにはテスト環境がなく、ほとんどの呼び出しは任意に実行できません（たとえば、停止は1回実行され、実際にサービスを停止します）。

この環境で単体テストを実行することは可能ですか？一般的な応答をシミュレートすることはできますが、サプライヤの応答をハードコーディングすると単体テストのポイントが損なわれるのではないかと心配しています。

いいえ、ありません。ユニットテストのポイントは、外部の世界とは無関係に、コードを分離してテストすることです。

システム全体をテストしてWebサービスなどの外部関係者とやり取りすることは、統合/システムテストです。これは、ほとんどすべての現実世界のプロジェクトでも必要ですが、単体テストとは異なるレベルです。実際にはあなたの状況のように聞こえますが、統合テストが難しいため、通常よりもさらに単体テストが必要です。

長期的な目標として、上記のサプライヤを教育および/または抑制して、自社とクライアントのテスト環境をセットアップすることを検討できます。ただし、これを成功させるには、管理者のサポートを呼び出す必要がある場合があります。テスト環境のビジネス価値について説得するために、難しい事実と数値を準備してください。

単体テストは、サプライヤに期待する動作の明確で実行可能な仕様も提供します。これはおそらく彼らとのコミュニケーションをずっと簡単にするでしょう。

両者の相互作用に問題がある場合は、ユニットテストを提供して、コードが期待する動作を明確に示すことができます。それらのコードが単体テストと同じように動作しない場合、通常は違いを簡単に特定できます。

ROI

これは本当に投資収益率の問題です。単体テストへの投資は、あなたが取り戻す価値があると思いますか。つまり、コードは単独でテストされます。単体テストの他のすべての利点と同様に。

これとは対照的に、サプライヤーからテストアカウントを取得して、統合システムをテストで実際にテストする自動受け入れテストアプローチと言えます。ATDDを実行するコストは、あなたが得るものに見合うものです。つまり、システム全体のテストです。

単体テストと自動受け入れテストの両方を行うか、どちらも行わないか、または他の何かを行う必要があるかどうかを分析して判断するのは、あなた次第です。