What I would like: testable mailers

September 2, 2012

Suppose that you are developing a change in your mailer's configuration files. There are very few 'clearly correct' changes to mailer configurations so of course you would like to test your change, to make sure that it does what you want and that it doesn't break anything.

If system administration worked like programming does today, you would fire up your suite of automated tests (they would probably be considered functional tests) and check that they all passed, both the old ones that verified existing functionality and the new tests you added to verify the change you're making. When your tests came up all green, you would have a pretty solid assurance that everything was good.

(Certainly you'd know that you weren't going to mangle email in any of the ways you've done it in the past, because you'd have tests to check for all of those.)

In today's world, well, this doesn't happen. The major reason it doesn't happen is that very few mailers are testable. Testability isn't just being able to test a program (you can always run the program by hand to test it that way); instead, it's the property of being easily tested by automated tests. To be easily tested, you need to expose the ability to ask the program questions and get answers that you can easily automate.

Today, a great deal of mailer functionality is not exposed this way at all and can only be tested through end to end tests where you set up a mailer, run messages through it, and examine the logs and the message deliveries to see what happened to them. When mailers let you ask them limited questions (such as 'what does this address expand to?'), the interfaces for doing this are usually intended for debugging mailer problems instead of verifying mailer functionality. As a result, the output is generally verbose, hard to parse, and not necessarily stable; after all, it was intended to be read by humans (who want a bunch of information and can sort it out themselves) rather than by programs.

A testable mailer would have interfaces that are explicitly designed to be used for automated tests. These interfaces would have stable and minimal output that directly answered your questions and let you control all of the context (in a sophisticated mailer, any number of decisions can depend on things like the source IP). This sort of testability would go well with a true programmable mailer, should we ever get one.

Written on 02 September 2012.
« Solaris 11 is still closed source (and Oracle is careless with words)
People are not ignorant (usually) »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Sep 2 23:25:20 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.