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?) 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"? 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 > > >
