Outlook Recipient test: always succeed / always bounce

Question

I am writing JUnit tests and would like to have an Outlook email recipient that will always succeed and a different one that will always bounce as undeliverable.

For the "always succeed," I think that the SMTP equivalent of NUL: would be helpful.

(I do not want to use my real email address for two reasons: 1) I don't want to get a test email every time someone runs the test bed and 2) I do not want to have regression tests start failing if my employer decides to eliminate my position and email address.)

For the "always bounce," I suppose I could use [email protected], but would be open to a more reliable technique that would not break if Mr. Nut joined MyCompany.

Along with "always bounce," I would appreciate any thoughts about how and where to look for the "System Undeliverable" messages. Should I use a test email account? Or perhaps a mocking framework to mock the bounce message?

---

EDIT: According to http://www.oracle.com/technetwork/java/faq-135477.html#bounce, the bounce message is standardized but not widely implemented. The email address validation is independent of JavaMail. Here's how I'd answer the questions in the last paragraph. A test email account might take some time before it gets the message, and I don't want to block on a message that is not guaranteed to be delivered. Mocking might make more sense.

Answer 1

Using mocks to validate processing logic of responses is definitely the way to go. Testing in isolation can only get you so far -- eventually you will need to write some form of integration test that communicates on the network to a mail server in order to validate the assumptions you've made for the unit tests.

In the past, I've had IT spin up a virtual machine with internal development only mail server. This mail server does not connect to the internet directly, but if needed routes through the company mail server.

Having your own domain controller / mail server provides you, the developer, greater control over features that would normally not be permitted via the corporate network.

Regarding handling different types of responses, I had a project where we needed to test different types of responses for meeting invites. We configured server-side rules for different email addresses so that certain crafted subject or body would auto-respond with acceptance, reject, etc. A server-side rule is simple to set up -- simply logon as that user (this is where the fake domain controller comes in handy) open outlook and configure a rule. More complex rules can be configured as part of an Exchange "Event Sink".

Still, as earlier suggested you should strive to separate the processing of the response from the sending action. In this fashion you can test the processing without the environment overhead.