Re: WicketTester feature request
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
Re: WicketTester feature request
2008/9/11 Timo Rantalaiho [EMAIL PROTECTED] Hi Timo, thanks for your reply. See below for comments. On Wed, 10 Sep 2008, Jan Stette wrote: I've had a few problems with WicketTester recently and would like to submit a request for when it gets overhauled for version 1.5 (is that still the plan by the way?): Depending on what exactly overhaul means (English is not my native language), yes it is :) Cool! It would be really useful to have a clean way to hook in code to execute pre- and post-request for operations that take place through WicketTester. In other words, some way to intercept all operations. In a real application, I can use a ServletFilter or override methods in WicketFilter to perform per-request initialisation and cleanup, but WicketTester doesn't execute its operations through these classes. So it would be very useful to do something similar when using WicketTester. I'm not sure I understand what are you trying to achieve. Do you have a concrete example? One example is where something like a Hibernate Session is initialised and a transaction created at the start of each request, then closed at the end of the request. So, to make the same steps happen in a test that uses the WicketTester. WicketTester (and unit testing in general) should aim to test one behavior of an object in a certain state per test execution. So the test methods should conceptually be something like Panel containing selected user - is visible - displays user data - stores changed user data It sounds suspicious if you do a lot of operations in a single unit test method. Longer integration / acceptance / functional tests are better done with a different kind of tool that is actually invoking the whole deployed application. Does this seem to make sense? 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! I've tried various ways for doing this. One was to extend the RequestCycle with code that it calls out to pre processing when created and post processing when detached. I found this didn't work as sometimes WicketTester will create multiple request cycles whilst performing a single operation, so I got multiple invocations to the pre code. Do you have an example of when multiple request cycles get created on a single operation? It sounds strange. Maybe the request cycle gets created ad hoc (as you mentioned) in some places without checking first whether there is one in place already. Looking closer at this to find an example, I've realised that it's our own extended WicketTester class that does this in a lot of cases, for reasons that aren't entirely clear to me. So it's probably our fault - sorry about that. (The guy who wrote this code is no longer with us so I'm trying to piece all this together...) Still, there seems to be one case where this happens with just the basic WicketTester functionality. First, creating a WicketTester: XWicketTester.createRequestCycle() line: 436 XWicketTester(MockWebApplication).init(WebApplication, String) line: 199 XWicketTester(BaseWicketTester).init(WebApplication, String) line: 205 XWicketTester(WicketTester).init(WebApplication, String) line: 308 XWicketTester(WicketTester).init(WebApplication) line: 291 XWicketTester.init(WebApplication) line: 65 Test(Test).initTester() line: 141 Test(Test).openLoginPage() line: 197 then directly afterwards going to a page: XWicketTester.createRequestCycle() line: 436 XWicketTester(MockWebApplication).setupRequestAndResponse(boolean) line: 547 XWicketTester(MockWebApplication).setupRequestAndResponse() line: 561 XWicketTester(MockWebApplication).processRequestCycle(Class, PageParameters) line: 370 XWicketTester(MockWebApplication).processRequestCycle(Class) line: 359 XWicketTester(BaseWicketTester).startPage(Class) line: 290 Test(Test).openLoginPage() line: 197 I can't see any call to RequestCycle.detach() between those two. Hope that makes sense at all... Regards, Jan
Re: WicketTester feature request
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 :) 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. However, in Wicket 1.5 the backwards compatibility requirement can be relaxed somewhat, so in there you have more chances of getting that kind of fixes in. And meanwhile, if the root cause of the problem is found, it's possible that there are viable workarounds for 1.3 / 1.4 as well. If you can provide a good patch to help resolve your problem, the chances of getting it fixed increase dramatically ;) Though the backwards compatibility point above remains. 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? Hope that makes sense at all... Sure, it is just a bit difficult to follow in this form :) Maybe you could create a working code example, such as a quickstart or even a JUnit test as a patch against the Wicket codebase? Then it would be easier to investigate further. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WicketTester feature request
Hi all, I've had a few problems with WicketTester recently and would like to submit a request for when it gets overhauled for version 1.5 (is that still the plan by the way?): It would be really useful to have a clean way to hook in code to execute pre- and post-request for operations that take place through WicketTester. In other words, some way to intercept all operations. In a real application, I can use a ServletFilter or override methods in WicketFilter to perform per-request initialisation and cleanup, but WicketTester doesn't execute its operations through these classes. So it would be very useful to do something similar when using WicketTester. I've tried various ways for doing this. One was to extend the RequestCycle with code that it calls out to pre processing when created and post processing when detached. I found this didn't work as sometimes WicketTester will create multiple request cycles whilst performing a single operation, so I got multiple invocations to the pre code. I also tried overriding WicketTester's MockWebApplication's methods processRequestCycle(*) but I found there were cases of operations where these would not be invocated. For example, BaseWicketTester.clickLink() will, in case of various Ajax components, create an ad-hoc request cycle and process this, instead of going through the application. This is with Wicket 1.3.3 by the way. If there's some other, better way to achieve all of this then please correct me and consider the feature request withdrawn... :-) Regards, Jan
Re: WicketTester feature request
On Wed, 10 Sep 2008, Jan Stette wrote: I've had a few problems with WicketTester recently and would like to submit a request for when it gets overhauled for version 1.5 (is that still the plan by the way?): Depending on what exactly overhaul means (English is not my native language), yes it is :) It would be really useful to have a clean way to hook in code to execute pre- and post-request for operations that take place through WicketTester. In other words, some way to intercept all operations. In a real application, I can use a ServletFilter or override methods in WicketFilter to perform per-request initialisation and cleanup, but WicketTester doesn't execute its operations through these classes. So it would be very useful to do something similar when using WicketTester. I'm not sure I understand what are you trying to achieve. Do you have a concrete example? WicketTester (and unit testing in general) should aim to test one behavior of an object in a certain state per test execution. So the test methods should conceptually be something like Panel containing selected user - is visible - displays user data - stores changed user data It sounds suspicious if you do a lot of operations in a single unit test method. Longer integration / acceptance / functional tests are better done with a different kind of tool that is actually invoking the whole deployed application. Does this seem to make sense? I've tried various ways for doing this. One was to extend the RequestCycle with code that it calls out to pre processing when created and post processing when detached. I found this didn't work as sometimes WicketTester will create multiple request cycles whilst performing a single operation, so I got multiple invocations to the pre code. Do you have an example of when multiple request cycles get created on a single operation? It sounds strange. Maybe the request cycle gets created ad hoc (as you mentioned) in some places without checking first whether there is one in place already. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
