That might be pretty cool! I can see how that might help constructing your unit tests.
On Fri, Sep 12, 2008 at 5:03 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
