GXT 3 and GWTMockUtilities
Was the issue with GWTMockUtilities ever solved?
See this thread:
Rather than stub out the widget subclasses, I would encourage taking a look at the MVP practices GWT is suggesting - the logic should be factored out from the view, and the view provides only access to data and events, not to raw widgets and elements.
Many aspects of GXT widgets are factored out into interfaces, such as IsField and all event handlers, but requiring that every class have a matching interface with all public methods would mandate mean that any public api change for any component will break tests. Separating view and dom from java logic completely removes this issue.
Many logical pieces of GXT 3 have been moved into shared package, indicating that they can be use in any envirnment, GWT or JVM. The main place this has happened is in the Stores and Loaders. Some of these though still must be in client: how can a HttpProxy be implemented exactly as a browser would do it?
http://code.google.com/webtoolkit/ar...e.html#testing is a good resource to get started with this idea.
This doesn't even come close to answering my question.
I already use MVP, and I would still like to mock some of my widgets for testing. So do a lot of people, based on discussions in GWT forums, and the thread that I linked to in which sven said that GWTMockUtilities support could be added to GXT 3.
So, I'm assuming the answer is "no" ?
At the risk of misquoting sven, I believe he indicated that such a change simply could not be made in 2.x - any such change could only begin to be made in 3. (EDIT: at the end of the thread he indicated we would expose interfaces as GWT is doing.)
Reading further in the discussion, Sven points out that using GWT.create is essential to building many things, especially we we start to make use of the appearance pattern, to allow the dom and event handling to be complete swappable. Many things, like the FormPanel or Html will simply not make sense when not backed by a browser.
As GWT has done, we are providing interfaces to interact with a subset of a component's functionality - event handlers, adding children, getting values all can be exposed, and can be used to swap real components for mocks.
There is still room for improvement in this area, but we are not planning on 1:1 component to interface. If you have some concrete examples of where we are missing interfaces or use cases that are currently impossible, please let me know, we'll work to get that in the next beta.
Tags for this Thread