Cool idea for testing ...

[Howard Lewis Ship <hl...@gmail.com>]

Wow. I just thought up a deviously useful idea for testing Tapestry apps.

Here's the problem; sometimes your pages are calling into a service
and need to handle some exceptional situation.  Maybe it is not
reasonable to get the service to respond with the exceptional case ...
in my situation, its about setting things up so that a database
transaction is rolled back due to a stored procedure noticing a data
irregularity that's pretty much impossible to set up through the UI.
I still want to test the logic in my page that handle the exceptional
response from the service, and I want to do it inside a Selenium-based
integration test.

I keep hearing "Uncle" Bob Martin whine "and why are our UI components
talking to our service components" (roughly paraphrased, from memory).

So I had this image pop into my head:

1) A mock implementation of the DAO service.
2) A special MockManager service that can temporarily store a Mock for
a particular service interface.
3) A MethodAdvice on the service that checks with the MockManager and
possibly redirects the method invocation from the real service
implementation to the Mock.

In other words, my test will obtain the service Registry (somehow) and
the MockManager.  It will store a Mock of my DAO service into the
MockManager.  My test then submits the form, and the page code invokes
a method on the service which is directed to my Mock.

I'll be prototyping this on my client code shortly, see how well it works.

If this works, it will really justify the fine-grained DAO approach
I've been using (pretty much each entity type has a cookie-cutter DAO
service)

-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: Cool idea for testing ...

[Howard Lewis Ship <hl...@gmail.com>]

The trick is going to be communicating the MockManager service out to
the testing layer ... it may need to be via a public static variable!

On Tue, Apr 19, 2011 at 3:54 PM, Igor Drobiazko
<ig...@gmail.com> wrote:
> I've been using something similar for PageTester tests. Every time I need to
> test something exceptional, I advise a service with a mock or stub. However,
> In integration tests It wasn't that easy to accomplish the same.
>
> On Tue, Apr 19, 2011 at 11:19 PM, Howard Lewis Ship <hl...@gmail.com>wrote:
>
>> Wow. I just thought up a deviously useful idea for testing Tapestry apps.
>>
>> Here's the problem; sometimes your pages are calling into a service
>> and need to handle some exceptional situation.  Maybe it is not
>> reasonable to get the service to respond with the exceptional case ...
>> in my situation, its about setting things up so that a database
>> transaction is rolled back due to a stored procedure noticing a data
>> irregularity that's pretty much impossible to set up through the UI.
>> I still want to test the logic in my page that handle the exceptional
>> response from the service, and I want to do it inside a Selenium-based
>> integration test.
>>
>> I keep hearing "Uncle" Bob Martin whine "and why are our UI components
>> talking to our service components" (roughly paraphrased, from memory).
>>
>> So I had this image pop into my head:
>>
>> 1) A mock implementation of the DAO service.
>> 2) A special MockManager service that can temporarily store a Mock for
>> a particular service interface.
>> 3) A MethodAdvice on the service that checks with the MockManager and
>> possibly redirects the method invocation from the real service
>> implementation to the Mock.
>>
>> In other words, my test will obtain the service Registry (somehow) and
>> the MockManager.  It will store a Mock of my DAO service into the
>> MockManager.  My test then submits the form, and the page code invokes
>> a method on the service which is directed to my Mock.
>>
>> I'll be prototyping this on my client code shortly, see how well it works.
>>
>> If this works, it will really justify the fine-grained DAO approach
>> I've been using (pretty much each entity type has a cookie-cutter DAO
>> service)
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de
>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: Cool idea for testing ...

[Igor Drobiazko <ig...@gmail.com>]

I've been using something similar for PageTester tests. Every time I need to
test something exceptional, I advise a service with a mock or stub. However,
In integration tests It wasn't that easy to accomplish the same.

On Tue, Apr 19, 2011 at 11:19 PM, Howard Lewis Ship <hl...@gmail.com>wrote:

> Wow. I just thought up a deviously useful idea for testing Tapestry apps.
>
> Here's the problem; sometimes your pages are calling into a service
> and need to handle some exceptional situation.  Maybe it is not
> reasonable to get the service to respond with the exceptional case ...
> in my situation, its about setting things up so that a database
> transaction is rolled back due to a stored procedure noticing a data
> irregularity that's pretty much impossible to set up through the UI.
> I still want to test the logic in my page that handle the exceptional
> response from the service, and I want to do it inside a Selenium-based
> integration test.
>
> I keep hearing "Uncle" Bob Martin whine "and why are our UI components
> talking to our service components" (roughly paraphrased, from memory).
>
> So I had this image pop into my head:
>
> 1) A mock implementation of the DAO service.
> 2) A special MockManager service that can temporarily store a Mock for
> a particular service interface.
> 3) A MethodAdvice on the service that checks with the MockManager and
> possibly redirects the method invocation from the real service
> implementation to the Mock.
>
> In other words, my test will obtain the service Registry (somehow) and
> the MockManager.  It will store a Mock of my DAO service into the
> MockManager.  My test then submits the form, and the page code invokes
> a method on the service which is directed to my Mock.
>
> I'll be prototyping this on my client code shortly, see how well it works.
>
> If this works, it will really justify the fine-grained DAO approach
> I've been using (pretty much each entity type has a cookie-cutter DAO
> service)
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>


-- 
Best regards,

Igor Drobiazko
http://tapestry5.de