[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Testing XML don't use xUnit

  • From: Ihe Onwuka <ihe.onwuka@gmail.com>
  • To: Michael Sokolov <msokolov@safaribooksonline.com>
  • Date: Fri, 12 Apr 2013 06:46:46 +0100

Re:  Testing XML don't use xUnit
On Thu, Apr 11, 2013 at 1:45 PM, Michael Sokolov
<msokolov@safaribooksonline.com> wrote:
> On 04/11/2013 06:37 AM, Stephen D Green wrote:
>>
>>
>> I also do a lot of work with testers writing tests for HTML pages using
>> the
>> very well-known integration test tool Selenium IDE (for Firefox) and that
>> makes heavy use of XPath even though the target is HTML. Here we end
>> up with many tests which include XPaths which break every time a
>> significant change is made to the HTML. So we have to keep mending the
>> XPath expressions (even though we try to write them with //, etc, to avoid
>> this). So I know the problem. It doesn't stop people favouring Selenium
>> IDE for website integration tests though. It's well worth the hassle to
>> many.
>> I guess it might be different if we were using XPath for unit tests but I
>> don't know about that. I guess modern unit tests get associated with TDD
>> and Agile, so maybe having separate test assertions (written in prose)
>> would be a 'no no' for many unit test writers as it might be seen as going
>> against Agile mantras. You'd have to update the assertions less frequently
>> than the unit tests but having to update something other than the tests
>> and the XML / code would be just too much for many Agile teams. So
>> if you wanted to inut test your XML you'd probably be stuck with having to
>> keep revising a load of XPath expressions. It goes with the territory.
>
>
> The problem with Selenium tests is not the tool: it's the markup.  HTML is
> not semantic markup, which means: it's not meaningful.  We can extract
> meaning from it, but its not easy because the underlying application logic
> (which is usually what we want to test) is not what people are thinking
> about when they are crafting the markup.   They're thinking about how to get
> pixels to line up on four different browser platforms.
>
> Selenium IDE is great for testing layout.  Not as good for testing behavior,
> but in some cases it's all we have.  We've had good success by working with
> the layout developers to get them to include meaningful identifiers in the
> markup *so that it can be tested*.
>
> If you want to make sure the price calculation is displayed to the user
> properly on a checkout screen, it's much more stable and testable if there
> is an id="price" attribute on the price display box.  Otherwise, if you end
> up having to write XPath like //div[@class="blue-box"]/ul/li[3]/span to
> select the price, you've lost the game.
>
> No amount of tooling support is going to allow you to write stable tests if
> the ground is constantly shifting underneath you.
>

So in my search to see how Selenium could help locate information
hidden in CSS I came across this.

http://selenium-training.israelekpo.com/targeting-elements.txt

Whenever possible, it is strongly recommended to stay away from using
unstable element locators such as xpaths to target elements
on the page. Xpaths are considerably fragile because minimal changes
in the structure of the HTML document could render current targeting
queries
invalid. In environments where the structure of the HTML document
changes frequently, keeping track of elements using XPaths can become
a maintenance nightmare.

CSS Selectors are strongly recommended over Xpaths.

In general, your choice of element locators should also not be based
on textual content in the HTML document,
whenever it is possible for you to avoid it.

Rather, it should be based on element identifiers, unique attribute
values or other structural information that is stable enough to
witstand
frequent changes to the web application without breaking the queries
used to look up the elements.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.