open a jira issue and we can whip it up -igor
On Fri, Sep 12, 2008 at 2:54 PM, James Carman <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
