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: [email protected] For additional commands, e-mail: [email protected]
