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
> > >
> >
>
