Comments on: How to test e-mail notifications properly

By: Alan

Alan — Thu, 18 Jun 2009 14:15:51 +0000

I have my own mail architecture which i’ve developed over several years so I essentially follow the same kind of pattern. Dump the message into a queue and get back to servicing web clients as quickly as possible. Let the mail queue do it’s job and pick up the messages as and when.

Interesting point regarding if the message ultimately fails to send – supposing there was a typo in the user’s e-mail address. How would the account ever be registered/validated/whatever? I guess we just have to hope that the duplicate e-mail address fields are enough to focus the user’s attention on typing it in correctly!

You could asynchronously the message from the web app in a thread pool thread or similar, but there is a finite limit to the number of threads etc. that can be processed at any one time. At some point the message has to be serialised and processed at a later time.

By: Andrea

Andrea — Thu, 22 Jan 2009 11:18:45 +0000

I think i m gonna use this post as a reference too for email testing, and how to go about it, Thanks very clear

Andrea

By: gojko

gojko — Thu, 06 Nov 2008 16:57:45 +0000

Hi Stuart,

FitNesse is not good for infrastructural code testing. it is great for acceptance testing. infrastructure is better tested using some code-oriented tool such as JUnit (these tests don’t necessarily have to be included in the basic JUnit test suite, you can separate them in a suite executed overnight). Testing the business part of the process (as suggested by the article) can be done with fitnesse without any waiting or anything. use an in-memory queue and read it directly to verify the contents.

the book is almost done. my copy-editor is looking at it now, and it should be out in late december or early january.

By: stu Taylor

stu Taylor — Thu, 06 Nov 2008 16:49:46 +0000

Hi Gojko,

have you tried testing email using FiitNesse? Its a total PITA.

I’m not saying its hard to implement, it just that you have to write a test that will sit around waiting for a queue to be processed, and email sent, then received, and then you can begin to make assertions on the email content.

The test has to be robust enough to not hang around forever (contain a timeout), and yet handle a slow queue or even an email that never arrives (the spam filter ate it, honest).

Cheers,

Stuart.

P.S how is the book coming? i’m looking forward to seeing what you have got in the QA section

By: Bob

Bob — Fri, 31 Oct 2008 02:01:17 +0000

Ben – your database system *is* a queue, and all queueing systems introduce some latency. But if your batch process runs every 10 minutes and also listens for a “run asap” message, then you can reduce your latency. The best case is everything works and the email goes very quickly, the worst case is that the database transaction commits but the notification is lost (which is the bug being avoided by having the transactional queue) and the user has to wait an average of 5 minutes before the email will actually be sent.

I wouldn’t install an entire message queue application for this purpose alone, and either do the quick and simple thing that you’ve done. But if the message queue system is used in other parts of the system, then I’ld use it directly. Also, the “send mail” interface should hide the database implementation, so if it changes the rest of the application shouldn’t need to be changed.

Eddie – “the email system” might work by magic pixies for all we know, but if the data doesn’t get from the application to “the email system” then the email will not be sent, and you’ll be a doofus with a broken site. And that has to be tested.