2008/9/12 Timo Rantalaiho <[EMAIL PROTECTED]> > On Thu, 11 Sep 2008, Jan Stette wrote: > > Absolutely, I see what you're saying. Part of the problem here may be > that > > on the project I'm working on, WicketTester is indeed used to do > > integration/functional tests. I'm not sure why this was done in the > first > > place, but it does seem to work - most of the time! I guess the API that > > WicketTester provides for performing actions like clicking links, > submitting > > forms etc. was convenient to drive from the system test harness, possibly > > simpler than actually driving a "real" web front end. > > > > Anyway, if this really is an abuse of WicketTester that you have no > > intention of supporting, then please say so! > > Well, I don't know if it's so black and white, but the > reality is that there are a lot of bugs and feature requests > in Wicket compared to the development effort available, so > prioritisation happens inevitably. In theory, it sounds like > a good idea to support RequestCycle lifecycle methods, and > it would make sense for WicketTester to mimic the real > behaviour as close as possible, but in practice it might > require some heavy debugging and coding that don't come out > of nowhere :)
Of course, I understand! And -- without meaning to put you off -- there's another > important point to consider, which is the backwards > compatibility of the changes. Making changes deep in 1.3 or > 1.4 WicketTester code at the moment might produce unwanted > effects in existing projects making heavy use of > WicketTester and having worked around its quirks. This can > happen even with legitimate bug fixes, and is sometimes > necessary. But sometimes you just need to leave bugs in, > because fixing them would break too much existing code. Absolutely. This was just a suggestion for something to consider for 1.5, I would not expect any of this to be changed in 1.3 or 1.4 at all. > Still, there seems to be one case where this happens with just the basic > > WicketTester functionality. First, creating a WicketTester: > > > > XWicketTester.createRequestCycle() line: 436 > > What is this line? Are you explicitly creating the > RequestCycle? Sorry, that's a call stack from our test code running. So that call to create a request cycle was made from line 199 in WicketTester's MockWebApplication.java. We have overridden createRequestCycle in our extended wicket tester, which is why it gives that class name. Anyway, your comments have been helpful for me to understand what the situation is regarding WicketTester, we'll have to have a think about how to best proceed. I would be interested in hearing about how other people do automated tests for their Wicket applications - but that's probably the topic for another thread! Thanks, Jan
