2011-05-25 4 views
6

私はJUnitテストを作成していますが、常に成功するOutlook電子メール受信者と、常に不達として返送する別の受信者を持っています。Outlook受信者テスト:常に成功/常にバウンス

「常に成功する」とは、NUL:というSMTPが役に立ちそうです。

(2つの理由で私の実際のメールアドレスを使用したくない:1)誰かがテストベッドを使用するたびにテストメールを受け取ることは望ましくない.2)回帰テストを開始したくない私の雇用主が自分のポジションとEメールアドレスを削除することに決めた場合には失敗します。)

「常にバウンスする」とは、私は[email protected]を使うことができますが、 Nut氏がMyCompanyに加わった場合、壊れないだろう。

「常にバウンスする」と併せて、「システム配信不能」メッセージをどこでどのように探し出すかについてのご意見をお待ちしております。テスト用メールアカウントを使用する必要がありますか?または、バウンスメッセージを模擬するための模擬フレームワークですか?


EDIT:http://www.oracle.com/technetwork/java/faq-135477.html#bounceによれば、バウンスメッセージが標準化が、広く実装されていません。電子メールアドレスの検証はJavaMailから独立しています。ここで最後の段落の質問に答える方法は次のとおりです。テスト電子メールアカウントは、メッセージを受け取るまでに時間がかかることがあります。配信が保証されていないメッセージはブロックしたくありません。モッキングはもっと意味があるかもしれません。

+0

@Bryanbcookはモックの使用について優れた答えを投稿しました。これはバウンスのために行く正しい方法のようです。それを送信するアドレスに関する考えは常に成功するでしょうか? – rajah9

答えて

2

回答の処理ロジックを検証するためにモックを使用することは間違いありません。孤立したテストはこれまでのところしかできません。最終的には、単体テストの前提を検証するために、ネットワーク上でメールサーバーと通信する何らかの統合テストを書く必要があります。

私はこれまで、内部開発専用のメールサーバーを持つ仮想マシンをスピンアップさせました。このメールサーバーはインターネットに直接接続しませんが、必要に応じて会社のメールサーバーを経由してルーティングします。

独自のドメインコントローラ/メールサーバーを使用することで、開発者は通常、企業ネットワーク経由では許可されない機能をより詳細に制御できます。

さまざまな種類の応答を処理する上で、私は招待状のさまざまな種類の応答をテストする必要があるプロジェクトを持っていました。特定の細工された件名や本文が受け入れ、拒否などで自動応答するように、さまざまな電子メールアドレスに対してサーバー側のルールを構成しました。サーバー側のルールは簡単に設定できます。偽のドメインコントローラが便利です)Outlookを開いてルールを設定します。より複雑なルールは、Exchange "Event Sink"の一部として設定できます。

まだ、前述のように、送信処理から応答の処理を分離するように努めるべきです。このようにして、環境のオーバーヘッドなしで処理をテストできます。

+0

私はbryanbcookがモックの使用を提案しています。http://mockito.org/ –

+0

@bryanbcookを使用することをお勧めします。編集とExchange "Event Sink"のリンクに感謝します。 SMTP配管の変更に役立つと思います。 – rajah9

関連する問題