This is a long story, so I'm going to try and get through it quickly in point form:
- I have pages that have dependencies injected into them that come from Spring. - I want to be able to test those pages using tapestry-test and PageTester, possibly with the real dependencies, possibly with mocks, although mocks would be my first choice. - If I do nothing, these pages end up having their Spring dependencies missing. No surprise there. - There are examples showing Spring dependency injection using modules; I can use that approach to inject the real dependencies, or look into tapestry-spring's internals in more detail. - If I want to inject mocks, I could write my own module binding to mock classes written myself without too much pain, I believe. - What I'd prefer to do is inject test-specific mocks created using Mockito; as a result, I want to inject custom instances on a test-by-test basis, rather than instances created from a class name. It seems like this goes somewhat against the grain of Tapestry IoC, and has been pretty slow going. To make this happen, I looked at a few options, an ObjectProvider (e.g. http://wiki.apache.org/tapestry/Tapestry5SpringIntegrationAlternative1) although tapestry-spring seems to now be using an ObjectCreator, which I know less about. I also looked at simply binding services ( http://markmail.org/message/2ams6no2hjndo67m). It seemed like the object provider was a layer more indirection than I actually needed. In order to get new services injected into pages with PageTester / Tapestry-IoC, I can supply additional module classes. A module /class/ wasn't going to do the job, as a class isn't a great carrier for configured object instances like mocks (at least not without using static variables, and risking ugly cross-test dependency collisions). However, I noticed that PageTester also has an abstract method for providing a module definition, so I wrote a thin wrapper of module and service definitions around a set of objects that I could define on a test-by-test basis. Unfortunately, before I could validate that approach, I hit a snag -- PageTester calls provideExtraModuleDefs() in its own constructor, which means that a subclass won't have had an opportunity to do anything like take additional parameters and store them in a subclass instance variable. This makes it hard to pass in a configured module definition with wrapped services into a page tester, which is what I was hoping to do. This leads to a few conclusions, I believe: - provideExtraModuleDefs() isn't very useful in its current form; PageTester could be refactored for better extensibility. - It's not easy to inject configured mocks as services into Tapestry IoC. - I'm going to have trouble following the approach I had in mind. Is anyone else using PageTester with mock instances like those created by Mockito or JMock? Is there a simpler/better way to accomplish what I'm trying to do that won't get hung up on the way provideExtraModuleDefs() is written? - Geoffrey -- Geoffrey Wiseman http://www.geoffreywiseman.ca/
