Yet another way IFRAMEs can get in the way of doing JsUnit tests..

---

We wrote a JavaScript object that represents a grid of search results. This object allows for a custom render function per column; in this case, we wanted to add an onclick handler for the cell that would change the source of an IFRAME. (I didn't choose to use IFRAME tags, that part of the implementation was done already.)

In our JsUnit tests, we created the JS object, got the custom render function for the given column element, called it, and then executed the onclick() handler for said element. (There were some assertions as well, but the code didn't get that far.) Firefox gave a really obtuse error:

[Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIDOMHTMLIFrameElement.src]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: file:////home/matt/src/projectX/js/searchResultRow.js :: anonymous :: line 29"  data: no]

Our custom renderer modified the "src" property of an IFRAME element, which immediately causes the browser to try and load the new src into said IFRAME. Because we were running locally, it was looking for the src on the local hard drive. It didn't find the src, so Firefox vomited up the aforementioned obtuse error.

We ended up testing it using Selenium , which is at least an order of magnitude slower than our JsUnit test. Selenium has its place, but JsUnit tests can provide more precise and actionable information about a test failure more quickly than Selenium can. This is mostly because JsUnit tests are generally written at the more granular unit-test level, whereas Selenium tests are generally written at the less granular system-test level. They're both awesome tools and they both have their place.

Yet another reason to avoid IFRAMEs, in my opinion. If I'm missing something that would allow us to unit test the modification of an IFRAME src property, someone please let me know.

Discussion: showing all 0 messages

(No messages)

>

Post a new message:

---