Thoughts about deeper PageTester integration

[Michael Wyraz <mi...@evermind.de>]

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). 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
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: Thoughts about deeper PageTester integration

[Alex Kotchnev <ak...@gmail.com>]

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 <mi...@evermind.de>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<de...@tapestry.apache.org>
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>