私は現在、デスクトップの電子メール クライアントに取り組んでおり、バックエンドの単体テストを行いたいと考えています。しかし、それを機能させる方法がわかりません。私のコードが機能するためには、機能しているメール サーバーに接続する必要があります。単体テストを電子メール アカウントに結び付け、アカウントがテストで期待される状態と一致していることを確認しない限り、これを管理する方法がわかりません。
設計上外部要因に依存しているこの種のアプリケーションをテストする方法について、誰かアイデアはありますか?
編集：
詳細を追加するには: 私は、C ライブラリである libEtPan を使用して、メール サーバーへの接続と対話の詳細を実際に処理する、アプリケーション用の C++ 高レベル メール クライアント ライブラリに取り組んでいます。
メールサーバーをモックし、そのモックされたオブジェクトを構成して、必要に応じてメールを受け入れ/拒否します (テストによって異なります)。
これを効果的に行うには、メール サーバーとやり取りするためのインターフェイスが必要です。テストのために、実装はモック オブジェクトです。展開では、これをメール サーバーと直接通信する実装に置き換えます。
C++ モッキング フレームワークについては、このSO の質問を参照してください。
バックエンドをテストすることで、実際に電子メール サーバーとやり取りするコードの一部を参照し、このレイヤーをモックした残りのソフトウェアをテストすると仮定します。
これは、定義ユニットに応じて、統合テストである場合とそうでない場合があります。率直に言って、あなたがそれを何と呼ぶかは気にしませんが、実行が速く、頻繁に実行される自動化されたテストを作成する場合は、単体テストと同じプラットフォームを使用することもできます。
少なくとも次の 2 つの方法で機能するように、これを記述しようと思います。1 つ目は、必要に応じてセットアップおよび構成できるプロセス ローカルの電子メール サーバーに接続することです。Java ではDumpsterを使用していますが、C++ にも同様のものが存在すると確信しています。2 つ目は、スクリプトを作成できる少なくとも 1 つのローカル電子メール サーバーに接続することです。好きなだけ飛び散らせて（実際のものでも、開発者間で共有しても構いません¹）、それに対して同じ一連のテストを実行できます。その理由は、SMTP サーバーの開発者は誰もが嫌いであり、スタブが本物と同じように機能することを確認する必要があるからです。これはOne Database Per Developerと同等だと思います。
独自の SMTP クライアントを作成しておらず、既存のサード パーティ API の周りにファサードがあるだけの場合、サード パーティ API が十分にボロボロになってバグがすでに発生していると仮定して、これを「統合テスト」する可能性は低くなります。サードパーティの API をモックして、ファサードが期待どおりに機能することを検証します。
1) CI サイクル中にこれを行うことができるので、すべての開発者間で 1 セットの電子メール サーバーを共有し、ローカル実行では C++ Dumpster を同様に使用します。
本物をスタブに置き換える方法を見つけなければなりません。それは完全にあなたの管理下にあります。通常、これはRhino.Mocksのようなモック フレームワークで行われます。
ところで、「実際の」メール アカウントを使用する場合、それはもはや単体テストではなく、統合テストです...
アンドリューは、メール API のモックについて正しいです。これがCにあるという問題は、2つの方法のいずれかで対処できます。
困難な状況での単体テストの方法について説明した優れた本があります。「レガシー コードを効果的に使用する」ですが、この本はあまりお勧めできません。タイトルに惑わされないでください。この本では、レガシー コードを単体テストのないコードと見なしています。
ほとんどの場合、ソケットの使用をテストしたくないため、コードのその部分を、TCP 通信をまったく含まないダミーのサーバー実装に置き換えることを検討してください。クライアントからの予想されるリクエストをハードコーディングし、ダミー サーバーが適切に応答するようにします。