Everything SQA

Selenium Relative Path Issues

Have you ever seen this stupid message after reloading a test suite in Selenium IDE?

error loading test case: [Exception… “Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFileInputStream.init]”  nsresult: “0x80520012 (NS_ERROR_FILE_NOT_FOUND)”  location: “JS frame :: chrome://selenium-ide/content/file-utils.js :: anonymous :: line 48”  data: no] 

And here is the annoying message captured from my MacBook Pro –

The fun part of this rather cryptic message is that there is one identifiable note that is repeated – and that is NS_ERROR_FILE_NOT_FOUND – which prompted me to load my Selenese test suite into my favorite web page editor. 

To my surprise – I noticed that the relative path is padded, and padded incorrectly.

This padding of the relative path occurs whenever you save a test suite in Selenium IDE (and in particular, this occurs on a Mac environment).

I played around on “The Google” and discovered that this problem also occurs on a variety of platforms, including Windows environments. During my time at bat, I’ve built a few Selenium test suites on Windows, and have never seen this before – since I explicitly give the root drive and absolute path to my test cases. When I reload my test suite, and select individual cases to edit from the Selenium IDE – I do so without issue.  Which led me to a solution…

So how do you fix it?

Well, add the absolute path to your test suite script – as such…

<tr><td><a href=”/Users/arterberry/SQA/master/0000 Config/setup_Test.html”>setup_Test</a></td></tr>

I simply replaced all of the relative paths with the absolute path – and reloaded my test suite. When I made updates to my selected test cases and saved them from the Selenium IDE – the path settings remained in place. Voila!

Stupid path issue thingy.

Selenium and Manual Test Case Generator: A Lesson in Passion

I often kick myself so hard that I think I literally perforate my insides. I don’t literally kick myself, but I do kick myself into overdrive, falling victim to my own inventions. But I usually become a victim to things that I am passionate about. And I have to admit, my passion burned through me like a raging sun flare late Friday evening. Earlier, I had been asked if I had written any papers, or published anything, and I failed to mention my blog. And although my blog is just an outlet, nothing grand on any scale, it is a bonafide example of my written efforts.  So without further thought, I decided I’d better add a little more prose to this lonely, remote spot in the deep digital ether. I sat at my desk and started cooking up an idea. An idea that focused on what I know best, and how I use it, and all from the comfort of my QA perspective.  I also opened my favorite web IDE, started up my dusty web server, and hammered out some code for a little proof of concept that became my personal singularity, which I gladly fell into.

Selenium and Manual Test Cases = peanut butter and chocolate

Web page testing can be a bit routine, and often repetitive, with the usual type of test cases that click on a link, or check out some text, or fill out a form, and identify expected result – yada, yada, yada.  No matter how rich the media, the procedure is often the same, but despite the ritual test tasks, a few gems stand out, like validating changing Ajax responses, applying performance metrics, parametric testing, or tweaking automation scripts. Since I often work with all of this, I started playing with the notion of adding what I love into one big fluffy utility.  I wanted to combine some of the same ol’ routines with some of the new and exciting routines – so I built a utility that could read the elements on a web page, generate a set of standardized manual test cases, while simultaneously building a copy of Selenium-ready test scripts. I felt like I was mixing some strange concoction that would appear weird at first, but somehow make sense in the end.

If you wish to bypass my long and winding write up, you can take a look at the demo that I built over the weekend. When you review it, please leave a comment if you think I can make some improvements. I call my friendly neighborhood tool TestDuo, since I’m creating two types of tests, and well - I’m not really good at creating buzz-friendly application names.

Keeping it simple
With TestDuo, I only had to concentrate on building three functional areas of the application. The iFrame which loads the web page under test, the manual test editor, and the Selenium test script editor. There is a fourth area of the application (that I actually disabled in the demo), which allows the tester to load a selected web page under test, within the domain that the user is testing in.

Basically, the app loads a web page under test, and builds a set of manual test cases, with expected results defined. The Selenium scripts are defined in the table form, and since I am focusing on links, I added the Selenium goBack function for every navigated link – so that the script can return to the scene of the crime. If you are familiar with Selenium, I built the scripts in its standard table form (without the header) so that the data can be copied into an editor other than the Selenium IDE.

Getting to know the DOM, at least one part of it…
The DOM has a wealth of properties, methods, and event handlers, all ripe and ready for picking, but since I have just a weekend to focus on my passion, I can only tackle a small portion of it with this proof of concept.  I decided to focus on links in the DOM, since they appear to be the easiest, and the most recognizable area for creating test cases.

My utility does look at the web page location, the images and some of its properties, but only from the point of identifying a potential web link. For example, when referencing an image with a link attached, I grab the image source and the alt -

var testImgSource = oTestFrame.contentWindow.document.images[iIndex].src
var testImageAlt = oTestFrame.contentWindow.document.images[iIndex].alt

- because those pieces are needed for Selenium, especially when constructing my XPATH.

Crossing the iFrame
While musing over TestDuo’s conceptual design, I wanted the iFrame to load web applications external from the current domain, but I quickly realized that my effort would be countered by necessary browser security features and W3C standards. But like all standards, I knew that there was a work around, somewhere out there…

Thank you Michael Mahemoff, who wrote a great blog post that focused on the fundamentals of iFrame’s and how to get around some of the issues that prevent cross domain communications.  The original goal of this utility will eventually allow it to work outside of the domain, with all types of web applications, and I will update this feature (along with a few other neat features) in the coming weeks.  

Improving the passion
After I get some of the tweaks tweaked, and some of the bells and whistles added, I plan on improving this piece of work by adding things like:

• Persistence. I would love to store these cases inside the application.
• Correct the cross-domain communication process.
• Parse all of the DOM and build cases for forms, images, and text validation.
• Improve XPATH building.
• Remove the paradox. I can load the application within an application, ad infinitum.
• Consider building this with Adobe’s AIR, or building it into a “lightbox” dialog.
• Make this open source for more input from the community at large.

And add whatever else comes to mind. This idea can be improved by leaps and bounds.

So how was your weekend?
This past weekend was a testament to my love of technology. I love the effort of building and improving things, and in a nutshell, I truly love what I do. I’m a “Toolsmith” who loves to tinker, and test things, and I want to demonstrate that daily. I’m truly inspired by people who share the same passion, and raise the bar with technology, which prompts me to step outside of my bubble, and try and do something interesting and exciting, and brand new. I really love QA, and the principles behind it, albeit I love it so much, that I often forget that I write about it.

It happens.

Maybe next weekend I’ll take it easy and just go to the movies.

Related articles by Zemanta

• QA in Software Projects with Sebastian Bergmann @ Dutch PHP Conference | Part 1 | Notes (tekkie.ro)
• Conversion process from Selenium IDE to Python (and its pitfalls/gotchas) (weblogs.mozillazine.org)