11

Some applications generate emails. There may be multiple email formats based on the purpose of the message. The email may be destined for a single individual or a group. It may also be locale-dependent.

How do I automate testing that (1) an application sends an email and (2) the content of the email is correct? (I am not trying to automate determining whether the email renders correctly.)

3
  • It is not clear from question if you want to automate the process of generating email content, the process of rendering HTML email content, or the process of verifying how the email looks like.
    – dzieciou
    Jun 30, 2016 at 16:13
  • I edited the question to clarify which aspects of the problem I care about.
    – user246
    Jun 30, 2016 at 16:31
  • You can use the free ahem.email service. It accepts standard SMTP emails tonits supported domains, and provides an easy to use web and rest api interfaces to consune the email content.
    – Oren Geva
    Sep 21, 2018 at 22:33

7 Answers 7

3

My preference is to have our email administrator create some 'public folders' for the QA team and tie them to a small handful of email addresses. That way everyone on the team has access to the received mails. If needed you can look at the header details of a message to be sure exactly what 'friendly name' it was sent to. It means mail sent to a large number of virtual 'people' in the system end up in a small number of folders, which makes it easy to see who got mail when without having to patrol a large number of email accounts.

Doesnt work so well for systems that require each email address to be unique however. In that case you may have to setup a large number of test accounts. You can get however much the same effect by having each one setup with a forward and delete rule that then routes those mails to a central clearinghouse, perhaps with a brief header saying 'mail recived for...' being added in. That still gives you one place to check for the mail (provided the forwarding rules run on the server and not on the client)

2
  • 2
    "Doesnt work so well for systems that require each email address to be unique however. In that case you may have to setup a large number of test accounts." Sometimes, you can create "unique" email addresses by appending a suffix to a single address. For example [email protected] is different from [email protected]. But Gmail will deliver both to [email protected]. Try it with your own gmail account! Jun 23, 2011 at 11:11
  • I'd known that caps made no difference and periods pretty much didn't exist in gmail addresses (johnsmith is the same as John.Smith) but of course that has a limited number of variations. The numeric suffix is a good trick, I wonder if systems like exchange can be setup to allow that Jun 23, 2011 at 18:15
4

You can give Dumbster a try.

Dumbster is a very simple fake SMTP server designed for unit and system testing applications that send email messages. It responds to all standard SMTP commands but does not deliver messages to the user. The messages are stored within the Dumbster for later extraction and verification.

Its written in java and is open-source.

1
  • Is there something like the dumpster for exchange email generation? Also is there support for testing Attachments? Lastly can I get it all for .net ;-) ?
    – Squirrel
    Jul 9, 2011 at 6:09
2

Also you may try Mailtrap if you don't want to set up and launch SMTP server locally. It is free web server that provides its own SMTP for e-mail messages debugging and testing.

1
  • +1 for relevant solution and welcome to SQA, Alexander! Note that according to FAQ you must disclose your affiliation in the answer if you describe your product
    – dzieciou
    Nov 3, 2012 at 19:14
1

If all you are interesting in is catching all the emails sent from an application then SMTP4DEV is a great little tool.

0

In addition to the fine approaches mentioned earlier, I have had success using a fake SMTP client that writes emails to a file system. Each message was written to a separate file in a directory named after the recipient. The file system approach had the advantage of simplicity; there was no SMTP server -- fake or otherwise -- to configure.

Our product generated emails from templates. It was important to ensure that the templating system worked correctly, but it was also important to ensure that the application supplied the correct data to fill into the templates. Testing the latter became a parsing problem. I ended up replacing our standard templates with simple ones that produced property files. So for example instead of generating this:

Dear Joe Doe,

Your current account balance is $125.

Sincerely,
JP Morgan Bank

we would generate this:

RecipientFirstName: John
RecipientLastName: Doe
CurrentBalance: 125.00
SenderBank: JP Morgan Bank

This way, it was easy to parse the generated emails.

0

Try out mailosaur.com It gives you unlimited real test email addresses and allows for automated and manual testing of emails.

We have Java, .NET, Ruby, Python and Node.js bindings to make it easy to integrate this in your Selenium (or other) test scripts.

Disclosure: I am a co-founder.

0

Most answers so far focus on automating the process of generating emails content.

Another problem is how to verify whether an HTML content of email renders well in different mail clients. Mail clients tend to be worse in that respect than Web browsers for Web pages, e.g., Outlook 2003 on Windows may render same HTML email different than Yahoo! Mail on Chrome or GMail app on Android. Verifying whether layout rendered by different email clients is what humans are good at and may be harder to automate. However, rendering same email in multiple clients again and again is definitely a good task for automation.

I have used litmus.com for that but I'm sure there are other companies on the market offering a similar service. With such a service you don't need to set up your own lab of multiple email clients. Instead you get screenshots of your email almost immediately and can focus on verifying the layout.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.