I have been working on some Email steps - kind of inspired by the pop3 step on the community site. I have the following core steps:
emailSetConfig (set up server params) emailStoreMessageCount (number of messages) emailStoreMessageId (find message id for a given message which matches given criteria) emailMessageContentFilter (extract message or part/attachment) emailMessageStructureFilter (extract structure of message - shows parts and content types) emailDeleteMessage (delete a message once you have finished testing it) emailStoreHeader (allows a header for a message/part to be extracted) emailStoreMessageType (determine if a message is Simple or MIME) emailStorePartCount (how many parts/attachments) emailStorePartFilename (the name of the parts/attachments) To simplify the interface I could remove the last 3 steps and perhaps the last 4 - the same functionality is available via emailMessageStructureFilter with a bit more work. I am seeking feedback on two possible options before I finished testing and documenting all the steps. Option 1: Leave all steps in. Normal use will be <emailStoreXXX .../> followed by <verifyProperty .../>. Advantage: steps are simpler and easier to explain to business representatives. Disadvantage: more steps to learn, more for us to maintain, can't use power of XPath to write sophisticated (possibly more concise) tests. Option 2: Leave out last (kind of redundant) steps. Use would require <emailMessageStructureFilter .../> which would change the current response to an XML file representing the structure of the message, followed by <verifyXPath xpath=.... /> Advantage: less steps to test, document, maintain, understand for new users, might be possible to write powerful XPath expressions which would otherwise take multiple steps or perhaps the use of test scripting, might be more efficient - currently the connection to the email server is closed between steps. Disadvantage: steps might be more difficult to explain to business users, need to think a little bit more when writing tests. Does anyone prefer one approach over the other? I am leaning slightly towards option 1 myself because I see webtest as playing a large role in acceptance testing and hence needs to be accessible for business users. Any comments? Cheers, Paul. _______________________________________________ WebTest mailing list [email protected] http://lists.canoo.com/mailman/listinfo/webtest
