we can always make it so there is a setting that outputs the full path as an attribute of a component if that is helpful.
eg <div wicket:path="some:path:to:this:div"> -igor On Fri, Sep 12, 2008 at 12:18 PM, German Morales <[EMAIL PROTECTED]> wrote: > 2008/9/12 Jan Stette <[EMAIL PROTECTED]> > >> Hi German, thanks for an interesting reply. >> >> Ruby probably wouldn't be appropriate in our environment, but it's still >> interesting to see the principles involved in writing tests using it. Some >> points I'm not clear about: >> >> When Wicket generates pages, as far as I can tell, the wicket:id that's >> stated in the markup just shows the local wicket:id, not the full path. So >> how can you refer to the item by the whole path, as in your example? (Is >> there a way to change which ids are rendered in the markup?) > > > Yes, the wicket id is not usable to search the components, because wicket > adds some extra characters in runtime. > > Normally, the "name" attribute should be good enough, and that's what we are > using. > > From FormComponent#getInputName: > /** > * Gets the string to be used for the name attribute of the form > element. Generated > * using the path from the form to the component, excluding the form > itself. ... > * ... > */ > > You should see attributes generated like: > panel1:panel2:form:panel3:innerForm:whateverElse:YourComponentID > > I'm also interested in what you say about using generated attributes. One >> of the problems we're facing is that our application is highly dynamic, the >> exact structure of a page depends on user configuration and setup. So I >> was >> thinking about something like using AttributeModifiers to set known ids on >> certain key components on a page. Is this what you mean by "generated >> attributes"? > > > Yes, that's a possible way. Also i was mentioning it for components that do > not have a name, like Links. > They are not FormComponents, but you still want to find them. > > >> Then, to make it all more interesting, there's Ajax. Our application makes >> heavy use of Ajax, so components come and go on a page in response to Ajax >> updates. I'm not sure which ids are available for identifying components >> in >> this case. Looking at pages in FireBug, I can't see wicket:id tags at all, >> but I'm not sure if that's missing something... Is this something you have >> dealt with in your testing? > > >> >> Regards, >> Jan >> >> >> 2008/9/12 German Morales <[EMAIL PROTECTED]> >> >> > Hi Jan, >> > >> > We are using Watir, which lets you write tests in ruby. >> > >> > And we are using mainly wicket generated names for identification of >> > components, but sometimes we use generated attributes too (for example >> <a> >> > does not have name), or just the text in the html. >> > >> > Since the code is all in ruby, it is in theory easy to refactor in case >> of >> > some changes. >> > For example, you can do this: >> > >> > textfield = ie.text_field(:name, >> "your:very:long:wicket:generated:name") >> > >> > or, in case of page changes... >> > >> > constant_defined_somewhere = "your:very:long:wicket" >> > textfield = ie.text_field(:name, constant_defined_somewhere + >> > ":generated:name") >> > >> > then you could fix all tests just changing the constant. >> > Well, this is an explanation of a quick solution to your particular case >> of >> > changing the hierarchy. >> > But the idea is that you have a full (and good) programming language to >> do >> > things "right": refactoring, reuse, and so on. >> > >> > Beware: >> > Watir does not always runs perfectly... the tests are somehow dependent >> on >> > timing, which depends on the machine you run the tests, and other >> factors. >> > This is specially problematic in ajax calls. >> > That means that sometimes we get errors, then we run the same test again >> > and >> > it works. >> > >> > Hope this helps, >> > >> > German >> > >> > 2008/9/12 Jan Stette <[EMAIL PROTECTED]> >> > >> > > This is a bit of a general question: I'd be interested in hearing about >> > how >> > > people do automated tests of their Wicket applications. I'm thinking >> > about >> > > system tests of the full application, not unit tests. >> > > >> > > There are of course tools like Selenium which let you automate actions >> on >> > a >> > > web application. My colleagues with experience of this from other >> > > applications tell me that one of the main challenges is to stop test >> > cases >> > > from being very brittle by relying on the details of the generated >> > markup. >> > > It would be nice if it was possible to target components on a page in a >> > way >> > > that related them back to roughly the hierarchy of Wicket components. >> Or >> > > even better, if individual parts of the page (links, input fields, >> > buttons >> > > etc.) could be identified in a way that didn't break when there were >> > > changes >> > > to the Wicket component hierarchy (say, new grouping components being >> > > inserted higher up in the component tree). >> > > >> > > I realise this isn't the responsibility of Wicket, but are there ways >> in >> > > which Wicket can help here, e.g. by generating ids or other attributes >> > > inside the markup in a way that makes it easier to locate items on a >> > page? >> > > Are there other tools than Selenium that people use, that makes things >> > > easier? >> > > >> > > I'm looking forward to hearing about how other Wicket users deal with >> > these >> > > issues! >> > > >> > > Regards, >> > > Jan >> > > >> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
