Michael, I definitely hear your mix of frustration & admiration of PageTester, I'm struggling w/ a mix of those myself. From what you're saying, it seems like you're heading into the direction of making PageTester a more end-to-end approach; I was personally struggling w/ finding a more barebones/unit-testing setup (e.g. where I would have less magic in the setup), but that's a different topic.
In the past, I recall struggling a bit of how to deal w/ testing an app that used Spring security and I eventually gave up on it . These days my app doesn't use Spring and uses Shiro for security and I was able to work Shiro in w/o too much trouble. On #1 from your list, I see how a more end-to-end approach that looks more like a full blown web app would make a page tester more robust in different application configurations that might use something more than just Tapestry. So, it seems like a +1 on that front. But then again, it starts stepping into the realm of the Selenium-based functional tests (the boundary there is already pretty thin). On #2 - I'm not sure why you want to additionally capture the rendered document. As you indicated, PageTester already does that. On #3 - I'm not sure why the PageTester's approach of starting up the application prevents it from being extended. Actually, so far it seems that the approach w/ being able to start up the application w/ a different set of modules has been quite flexible for me. I've had issues w/ how the selenium based tests start up the application, but that's a completely different story. Finally, I'd be curious to hear on your approach w/ making this happen. The Testify project already has a few enhancements (w/ being able to inject dependencies into the test,etc). Were you going to tackles these yourself ? Cheers - Alex K On Mon, Aug 13, 2012 at 8:34 AM, Michael Wyraz <[email protected]>wrote: > Hi, > > I tried to make PageTester work with our application. The problem is that > the application needs Spring where Tapestry5 pages and modules accesses > Spring beans and Spring beans accesses Tapestry services. This works fine > within the Web container. but not with page tester (even not with the > change described in the wiki http://wiki.apache.org/**tapestry/Tapestry5-* > *TestWithTapestry-Spring<http://wiki.apache.org/tapestry/Tapestry5-TestWithTapestry-Spring>). > The application also requires some custom filters (e.g. OpenSessionInView > filter) and stuff like a Spring ContextCustomizer which are completely > ignored by the pagetester. > > I tried a lot to get it work but everytime i solved a problem I found a > new one. So I started a completely different approach which allowes testing > of the unchanged application which I'd like to discuss. > > 1. Emulate the whole servlet container > This sounds more heavy than it is. I simply parse the web.xml and create > Servlets and Filters+FilterChains from it using MockServletConfig and such > from spring testing. So I simply need to set up a MockHttpServletRequest + > a Response and pass it to the FilterChain. This allows me to start the > whole application with all filters including Tapestry with a few lines of > code. Surprisingly the started application works out of the box including > all the Spring/Filter stuff. > > 2. Capture the RenderedDocument "in container" > ATM I just did some tests if it is possible. Here's how I imagine that it > could work. This approach would also allow real In-Container-Tests using > the famous PageTester: > - a special marker will be added to the ServletRequest that identifies it > as test request (e.g. a special header) > - A special filter in the servlet filter chain (1st filter) looks for this > marker. If pressent, it creates a special ThreadLocal object that signals > the application that this is a test request. This ThreadLocal object will > later holt the rendered Document. Request and Response are replaces by some > wrappers. > - A tapestry markup filter similar to the one provided by the pagetester > module looks for the ThreadLocal object and puts the rendered document to it > - after all processing, the special filter takes the rendered document and > returns it as serialized object to the servlet's output stream. > > 3. Modularize PageTester > - Since PageTester always tries to instanciate teh application, it's not > possible to extend it. There should be a PageTesterBase class that holds > the pagetester logic and delegates everything that is required for > conneting to the application to abstract methods. > > I'm looking forward for your comments to this approach. > > Regards, > Michael. > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@tapestry.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
