You get a list of all URLs on the page by using the getHtmlSource command to get all of the HTML source code from the page. You can then use either a regular expression or HTML parser to extract what you’d like. In this case; all of the a href elements on the page.

If you’re using Selenium, you can the following code into your script.

This will open up yahoo.com in Safari and get a list of all the link on the page and put the output into your console. If you use this as a function for every page that loads, the output in your console could get pretty lengthy if you’re dealing with multiple pages. It would be better to have this output in a text file.

So a lot of people have been asking me about how to create JUnit Reports with their automated test cases. I’m going to show you how to create these reports in the easiest way possible. You will not have to download anything, add any code, etc. You will only have to use generate the HTML report using Ant with Eclipse.

The first think you have to do is generate the Ant build. You can do this by:

1. Right click on the project and
select Export –> Ant Buildfiles (this will be under General) –> Next–> Select the project that contains your JUnit tests –> Finish.

The default JUnit output directory is appropriately named “junit”.

2. The next thing you have to do is resolve your dependencies by making sure that the junit.jar is added to
Ant’s “Global Entries.”. You can do this by.

Window->Preferences->Ant->Runtime->Global Entries and Add External JARs… Navigate to your “eclipse” directory (where eclipse is installed). It is under “plugins” directory and presently the junit.jar is in a directory named “org.junit_3.8.1”. If this is missing then you will see error messages since
junit is an optional Ant task.

* If you are using a Mac, Preferences are under the the Eclipse menu.

3) Finally, right-click on the Ant build file build.xml (this file is the one you created in Step 1) and Run As->Ant Build. This will display a list of targets. All of the launch configurations you have previously configured will have a corresponding target in your Ant build file. Select the desired target(s), and also select the “junitreport” target (very important). Check the “Target execution order” text area to make sure the junitreport is run last.

As you can see I’ve specified the order in which I want my cases to run (below)

Whenever you run a test case it will generate results and will be placed in the junit output directory. These results are formatted into an HTML report by the junitreport target and stored in the junit output directory.

As you can see below my automated Test Suite has completely run and you can see which tests failed and which passed (below). I see my cases for login, registration, and account-sign up are failing. Upon further investigation, these are failing because the web service is down on our staging server.

This is a fast and easy explanation of how to create JUnit HTML reports, but hopefully it helps get you off your feet. Next time around, we’ll have some more fun when I show you how to extend this output to get more information displayed in the report. For example to add an additional column which contains link to a screenshot taken by the test.

Devices that have large screens and a high resolution can appear quite large in your computer screen. This is because DeviceAnywhere Studio renders the device pixel-for-pixel, so a device with a higher screen resolution than your computer will appear larger than its actual size.

You can easily change the size of the device in Studio by right-clicking on it and selecting Zoom > Medium Size or Small Size. Alternatively, to zoom in to see a section of the device screen more closely, you can select Super Size.

Note that Studio remembers the most recent zoom setting for each device you acquire. For example, if you change a device’s zoom setting to Medium Size, the next time you launch Studio and acquire that same device, it automatically appears at Medium size.

QA resources are frequently tasked with some kind of email tesing. Usually this consists of making sure that all the links in the emails work, the Subject lines and content is correct, and most importantly the most neglectful aspect of testing, mail client/cross-browser testing.

I’ll limit this discussion to testing emails in Outlook because this is usually where UAT happens with you clients viewing this email. For those that are new to email testing with Outlook, the latest version of Outlook, 2010, similar to Outlook 2007, uses Microsoft Word’s rendering engine to display emails, impacting the appearance of emails.

Microsoft again, is relying on Word rather than Internet Explorer in part for security issues. Thanks to the Component Object Model relationship between Office components, the tool to write formatted emails arrives to Outlook through Word. And it remains unchanged with Outlook 2010.

So what does this mean, when you’re dealing with testing emails that may have to display properly in Outlook 03,07,and 2010 you only have one machine at your disposal to accomplish this goal, You’re best best would be to have Microsoft Office 2003 installed on your machine. But why?

Well, Outlook 2003 uses Hotmail’s rendering engine to display emails, so how can you see how it would in that application. But what about the display in 2007 and 2010?

Try this:

1. Open the email that has arrived in your inbox in Outlook 2003.
2. Save the email as an html file.
3. Open up Microsoft Word 2003 and open up the html file.

What you will see is exactly how that email would display in Outlook 2007 and Outlook 2010 because you are actually using Word’s rendering engine to see the email. The same engine that shows you how crappy the email looks because of a lack of css support.

So there you have it. I know 2003 is quite old, but surprisingly trying to explain to one of your clients who uses Microsoft 2003 to look at emails, why the email looks pretty crappy, may just save you some unnecessary back-and-forth. This is especially important because you can’t actually use Hotmail to see the display for a 2003 mail client anymore, since Hotmail is now Windows Live Mail and they’ve dropped support for a number of properties and a number of key CSS selectors.