(Originally published on the Mailinator blog) Terminator 2: Judgement Day is possibly the finest of the Terminator films. It retained a lot of the spirit of the original Terminator but added better special effects and a killer song by Guns ‘N...
(Originally published on the Mailinator blog)
Terminator 2: Judgement Day is possibly the finest of the Terminator films. It retained a lot of the spirit of the original Terminator but added better special effects and a killer song by Guns ‘N Roses. The name of the software I’m about to talk about, Mailinator, always reminds me of one of the most memorable lines from T2, “Come with me if you want to live”. But first, a little context…
In a previous organization, we needed to create “sufficiently unique” account information so that automated account creation would not need human intervention; in production, the “human intervention” was to prevent fraud and to handle the “same human with different info” scenario. To complete the automated testing of account creation, the process also required that we check the “account created” email. At that time, Google Mail, i.e., Gmail, afforded us that capability via the “email address plus” syntax.
For our automation implementation, we created a “work-only” Gmail account to which we sent all our account creation emails via the “plus” address syntax. The general format of the generated email addresses was myworkgmail+randomstringandtimestamp@gmail.com. This approach served our purposes because the email address was tied to our “work-only” account and we could create sufficiently unique addresses. These addresses allowed our account creation flow to succeed with no human intervention while having a known place to manage the “creation completion” emails.
There were challenges, of course. First, we were sending account creation information to some Gmail account that one of us created; Gmail account creation required the creator to specify some personal or company information. Yes, for us, this information was being used for a pre-production environment, but not all use cases are as forgiving. Also, the credentials for this Gmail account needed to be sufficiently well known so that all test scripts could potentially access the account and so that humans could also access it for debugging purposes. Humans with those credentials could have performed malicious or unethical actions with relative anonymity; fortunately, and quite by design, our team comprised a group of trustworthy and ethical people. We acknowledged and tolerated the security concerns. Again, not all use cases enjoy this luxury.
Despite concerns about wrongdoing, we needed our automation to find and access the appropriate email for a specific test script run that created specific account information. Due to the Gmail APIs available at the time, there was additional code needed to handle both the waiting for and the filtering of emails. It was completely doable, but the code was a bit brittle due to the nature of how we needed to use the API and the “plus” addresses.
Fast-forward to the now-times. I was recently introduced to an application called Mailinator.
Alert! I don’t usually write about specific products’ features; I’m making an exception here because this product might have been appropriate for us in the previously described organization. As a consultant, I need to be able to work in many product environments with many different tools, but I also need to be in a position to make product and tool recommendations for my clients. My comments about and experience with this software are based on my background, possibly having a client that would benefit from a product such as Mailinator, and building a prototype with it. Had I known about this product back in the old days, we definitely would have created a prototype with it to assess its appropriateness for us.
For my previous implementation, a helpful Mailinator feature is what I call “virtual inboxes”. If I have a Mailinator account and I send an email to voivod@myaccount.testinator.com, I can use a REST API to grab all of the emails sent to the “voivod” inbox of the account “myaccount.testinator.com”. This feature makes searching more straightforward, and has fewer lines of code because I can grab only those messages sent to the account “voivod”; I don’t have to filter messages that some other test scripts sent to helloween@myaccount.testinator.com because of how these inboxes work. Wait, you want all the messages to all inboxes for your account? The API allows that too.
Back to my “in the before times” use case…
Due to the previously mentioned uniqueness requirements, our test scripts would create the sufficiently unique information, including the email address, to create a new account. With the Gmail approach, we had to grab groups of the messages from the Gmail account and then check if ours had arrived, meaning sniffing the addresses of each of the newly arrived emails; if we had been running in a high throughput environment, we could have had unhandled race conditions due to missing the expected emails because the email’s arrival fell outside our expected message group. With Mailinator, I like the fact that I can write my REST “query” to access just the address that I want to get messages from; for my use case, it would have eliminated the need for sniffing email addresses. Yes, with Mailinator, I do still have to implement polling code to wait for my message to arrive, but that’s the nature of asynchronous programming; sometimes we have to wait for things to arrive or to occur.
Is Maillinator the right tool for every job? If you’re working “small”, a few test scripts and a single test account would let you be “responsibly lazy” in how you retrieved and processed email messages. In a highly parallelized automation environment where many test scripts are executed in parallel, email processing via Mailinator would be an effort saver.
Oh, wait! I forgot about two-factor authentication, i.e., 2FA! Back in my previous role, 2FA was seldom a concern, if it was implemented at all. Fast-forward to 2023. Today, without hyperbole, I used 2FA via email. If we blend account creation notification and 2FA via email in the same test script, we now have potentially two different emails to the same address to handle an initial account test. For lower volumes, the “Gmail plus” approach may still be convenient, but for teams or organizations running in parallel in a CI/CD/CT pipeline, the coding for email handling could become an appreciably higher effort. YMMV.
Want to see the C# version of the demo I created? You can check it out here: Paul Grizzaffi’s Demo
Wait! You need to do 2FA via SMS/text in your test scripts? I recently found out that Mailinator does that too, but as Alton Brown says, “That’s another show”. Stay tuned!
Like this? Catch me at an upcoming event!
