Jim is right on the money here, I'm probably going to somewhat end up restating what he said.
This issue of finding a consistent way to identify the objects within the dom is not unique to Watir, it exists for ALL automation tools to one degree or another. Watir provides a large variety of ways with which to identify most objects, most typically in a situation like yours either NAME, ID or CLASS end up being the most widely supported and hence most useful, sometimes along with Index when there is more than one of the same type of item on the page. Another alternative is TEXT but that's in my experience more subject to change, and also creates issues if your site supports more than a single language. So typically one of these others (and you only need ONE of them) is a better way to go if possible The problem with auto-update tools is that to be effective, they need to be nearly of an AI level of ability to analyze the page. and if there is some consistant way that the 'auto-update' tool would be able to use to tell 'oh the id from that changed from "Login_Button" to "Signin_Button" well then likely that's how you should be identifying the object in the first place.. Auto-update sounds nice, and sexy, but it's incredibly difficult to implement reliably (or everone would have it).. The tools I've seen that have it, often fail to live up to what's promised when you start using it in real life. Really this comes down to a sort of 'contract' between yourself and the developers. You need some reliable, predictable way to identify items in the UI, and they need to provide that to you. This might be via adding 'name' properties to things if they don't have them, and then seeking to minimize the number of times those values ever change. Or it might be doing the same thing with ID.. Realisticly it's not asking too much I think for them to give you some simple, non- changing, reliable way to identify UI elements. Tell them what ways this could be done (e.g. via name, id, or class) and let them pick whichever is easiest for them to deal with. That lets them stay more in control of what they are building while at the same time making it more testable, and it's less likely to cause strife due to a preception of 'test telling us how to code'. Odds are they may not even be aware of the pain they are causing you, and a few simple words with them, or a few minutes in their daily standup etc could make them aware of the problem, and quickly pick a solution. So really just starting off with 'guys I have a problem, I hope you can help me solve it' and explaining the issue may get things on track with a minimum of pain and effort for all involved. Some changes will always end up occuring, but with a little co- operation from the devs that can be kept to a minimum. And the maintaince for that can be greatly simplifed by using some kind of central object repository that associates a logical name with the page element, so the scripts using the logical name, and if the idenfication changes, you just make a change in one place (the repository) In terms of reducing the pain when things do change, some kind of Object Repository is generally the best way to go. The Watircraft framework (and the Taza framework as well I believe) for example handles this via 'page' files that allow you to have one place where all elements on a page are identified and given logical names. Then if an ID for a button changes (and you were using that to identify it) you've got one place to make a change, and everything is working again. If your tests for a given page start by checking to see that all the expected elements of the page are there (e.g. .should exist) then you've just in a sense built a part of what you are describing in terms of your 'auto-checker' at least with regard to validating that you can identify all the expected elements on the page (well, other than if identifiers are swapped around, that might go un-noticed if you are just looking to see that things exist) Something like this might also help to quantify the current problem (how often and how many things are changing), giving you the amunition you need to take this issue to management and maybe get some cooperation from dev. .. so it might be a good approach to take (starting off with a really simple series of tests that just hit every page and try to see if they find all the expected elements on each page) along with then documenting the results, and the time to modify the OR to update it for changes. Once the simple 'is everything there' screen passes you would probably then be good to run the main suite of tests. Hopefully you won't need a big club to get co-operation from dev, but if you do, documenting the frequency and volume of 'id churn', along with the time it takes to compensate for it, should provide you with a pretty stout clue-bat that can be used to wake up those needed to mandate that things have to change for the better.. --Chuck On May 14, 9:18 pm, Lokesh Agrawal <lokesh.agra...@gmail.com> wrote: > Hi All, > > Thanks for the reply. > > I am already using IE development toolbar, but that's not the issue. > > I think Jim is very much clear in his statement and I have to talk to > developers and manager for this problem. > > BUT I think it will be good for future of Watir if we can have some > object identification/discovery facility. May be before running any > test suite automation testers will first run object discovery which > will store all objects (with properties) in some file and will compare > with old ones. > > I found one framework with this approach: JAF (http://90kts.com/blog/ > 2008/just-another-framework-for-developing-watir-test-cases/). > But I have not used it so doesn't know if this is helpful or not. (As > this framework is using RSpec while I am using Test Unit). > > Thanks and Regards, > Lokesh Agrawal > > On May 14, 10:16 pm, sHiVa <krapa.ph...@gmail.com> wrote: > > > > > Lokesh, > > > I can suggest one solution to your problem even developers will not > > helpful. > > Try to manage all of your object properties in a single place > > (repository), that may be a XML, EXCEL, or in ruby file itself. > > > 1. Try to track most frequently changed properties in your script. > > 2. Use regular expressions where ever it is necessary > > 3. Don’t hard code object properties in the script. Instead of it, > > just call the properties from outer world > > 4. Try to use :index property if some objects are every time > > changing. > > > These following practices will surely help you. If you need further > > help managing object properties in a single place, let me know. > > > Regards > > Siva Phaneendra Krapa > > Virtusa.- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Watir General" group. To post to this group, send email to watir-general@googlegroups.com Before posting, please read the following guidelines: http://wiki.openqa.org/display/WTR/Support To unsubscribe from this group, send email to watir-general-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/watir-general -~----------~----~----~----~------~----~------~--~---
