Outlook recipient check: always succeeds / always bounces

Question

I am writing JUnit tests and would like to have an Outlook email recipient that will always be successful, and another that will always refuse as invalid.

For “always succeed,” I think the SMTP equivalent of NUL: would be useful.

(I don’t want to use my real email address for two reasons: 1) I don’t want to receive a test email every time someone starts a test bed, and 2) I don’t want regression tests to start failing if my employer decides exclude my post and email address.)

For “always failing,” I suppose I could use [e-mail] , but would be open to a more reliable technique that would not break if Mr. Walnut joined MyCompany.

Along with “always failing,” I would appreciate any thoughts on how and where to look for “System Undeliverable” messages. Should I use a test email account? Or maybe a mocking structure to mock a denial message?

---

EDIT: according to http://www.oracle.com/technetwork/java/faq-135477.html#bounce , the bounce message is standardized but not widely implemented. Email verification is not dependent on JavaMail. This is how I answer the questions in the last paragraph. An email account may take some time before it receives a message, and I do not want to block a message that is not guaranteed. Sense may make sense.

Answer 1

Using mocks to test response logic is certainly the way to go. Testing separately can only bring you to the end - in the end you will need to write some form of integration test that communicates with the network on the mail server to check the assumptions you made for unit tests.

I used to have a virtual machine with an internal development-only mail server. This mail server does not connect directly to the Internet, but if necessary routes through the company's mail server.

Having your own domain controller / mail server gives the developer more control over functions that are usually not allowed through the corporate network.

As for handling various types of responses, I had a project in which we needed to test different types of responses for meeting invitations. We have configured server rules for different email addresses so that a certain processed object or body will automatically respond with acceptance, rejection, etc. The server-side rule is easy to configure - just log in as this user (here a fake domain controller is useful) to open the look and configure the rule. More complex rules can be configured as part of the Exchange "Event Sink" .

However, as suggested earlier, you should strive to separate the processing of the response from the sending action. This way you can test the processing without the overhead of the environment.