This is great for testing the server-side code, but kind-of turns into an integration test when what you want to exercise is client-side code (e.g. an MVP presenter).
The complexity of having so much types (RequestFactory, RequestContext, Request, and of course proxies) to mock (not to mention their expected behavior: many Receivers called back for a single RequestContext#fire; Request#to returning the RequestContext back, etc.) has, sadly, led us to actually have almost no test for our client-side code; because no one ever took the time to build a "testing framework" for RF. It's still possible to directly make use of RequestFactorySource in this case, by providing mock services, but RequestFactory caches service locators and services in static fields, which would break test isolation (this can be an issue even when testing the server-side code; I worked around it by resetting the static caches using reflection, just after initializing the ServiceLayer; that works because CachingServiceLayer also keeps non-shared instance/local references to the "cache"). IMO, such a tool would have to build on top of the existing abstract implementations (AbstractRequestFactory, AbstractRequestContext and ProxyAutoBean), and possibly RequestFactorySource (or a "fork" of it). You'd then either provide mock services (disabling the CachineServiceLayer, or at least its global/shared cache, for the tests), or get a handle on the AbstractRequestContext's invocations and editedProxies (with a helper to easily get "operations" back) and provide mock return values (e.g. "client code → fire() → assert invocations and operations → provide response → "fire" response –would call the Receivers back– → assert client code behaves as expected"). There would obviously need to be a way to create proxies (object graphs) without attaching them to a RequestContext for faking responses. The only alternative I can see would be to hide RF as an implementation detail behind some kind of "RPC" or "DAO" interface, so you'd mock that interface instead of the RF, RC and Request ones (that wouldn't solve the issue with mocking entire graphs of proxies, which would be painful). -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/JoOdJ3ikPqQJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
