0

I have a scenario in my application which clicks the support link and opens an email draft with the support email id. I need to verify the email id using Protractor.

Danny Fardy Jhonston Bermúdez
  • 5,500
  • 5
  • 25
  • 37
Nalu
  • 195
  • 2
  • 13
  • post your code and the page which we can see support like and the opened email – yong Nov 11 '17 at 00:00
  • I have not added any code yet. I have to test this scenario for E2E testing.But not sure how to start. The goal is there will be a draft email opened which contains support@unique.com. in the To list.I have to read this value and validate – Nalu Nov 11 '17 at 00:03
  • protractor can only automate browser, if your mail is not launched in browser, for example outlook, protractor can't test it. that's why I ask you to give a screenshot of your age and mail. If your mail not launched in browser, on Windows you can use AutoIt (another tool) to write a script and build it to an exe (AutoIt support that), use NodeJS process api to call a windows command to run the exe. AutoIt only work on Windows, if you need to run the test on other OS, you need to take more considering. – yong Nov 11 '17 at 00:16

1 Answers1

0

I guess that is one of those cases, when you're much faster and better with manual testing.

But to give first an option for Automation:

Probably the scope of the application under test ends on what gets provided as HTML or evtl. JavaScript. After that it's basically Browser and OS functionality that opens the mail software. Therefore your tests should only cover what's in scope of your application under test.

So the suggestion to automate is to just check the element, containing the mail-link (evtl. mailto:), if the attribute is set correctly there. Something like this:

expect($('div.support-mail').getAttribute('outerHTML')).toMatch('support@mail.com');

Read in this SO-Question here more about alienating users without set-up mail software as well as further infos, how a mail-address can/shall get published.

Now, why it's better to do it manually:

Just imagine the complexity and variety you'd need to cover within your automation code:

Only for Computers it already means

  • 3 main OS (Windows, Mac, Linux), times

  • 5 Browsers (IE, Edge, Chrome, Firefox, Safari), times

  • countless mail software (Outlook, Mac, GMail, Yahoo, etc.)

  • further to add: Browser extensions and pop up blockers, which prevent mail from opening. OS, where no default mail is configured, etc.

If you additionally add Mobile Coverage (Devices, OS, screen size, etc.) it goes nuts.

You'll be in maximum able to cover a few environments, no matter with or without automation. But with automation it will take you many hours to get a decent running version, while a manual test will take you 30 Seconds per execution. So if you manually test about 20 environment setups this will still take you less than an hour. And you'll need to test it maybe twice or three times a year.

Also this functionality will probably never change again, so once verified it's working, it keeps working. If Code standard or browser changes significantly one must maybe retest once a specific configuration.

Last but not least this isn't business critical functionality. In worst case your users need to copy-paste the address from Browser into their mail.

All in all I'd consider this case not worth the effort for automation. Manual Testing suits better here.

Ernst Zwingli
  • 1,402
  • 1
  • 8
  • 24