I'm pretty new to RF but by reading through various posts regarding
the testing of RF i came up with the following solution that seems to
work well so far with spring
First an abstract test case that your unit test would extends
@TransactionConfiguration(defaultRollback = false)
@ContextConfigura
I came with an thin abstraction layer over request factory. My presenter
declare an inner interface called DataService which exposes methods from RF
that are needed for that presenter. For exemple:
public class PesquisaPresenter {
public interface DataService {
void findById(long id, Receiver rec
It doesn't "has to", but that way you're really, really sure that the cache
is local to the CachingServiceLayer instance (in case you forget to clear
the field in another test running in parallel, it might thus reuse the same
cache, so it might populate it with its own services before your test
>methodCacheField.set(null, null);
Why it has to be done twice? (before and after creating the service layer)
On Fri, Sep 2, 2011 at 11:22 AM, Thomas Broyer wrote:
>
>
> On Friday, September 2, 2011 4:19:28 PM UTC+2, Thomas Broyer wrote:
>>
>> serviceLayerCacheClass = Class.forName("com.go
On Friday, September 2, 2011 4:19:28 PM UTC+2, Thomas Broyer wrote:
>
> serviceLayerCacheClass =
> Class.forName("com.google.gwt.requestfactory.server.ServiceLayerCache");
>
>
Oh, sorry, I'm still working with an old version of GWT (r9848 –that's
between 2.2 and 2.3– with a handful of pat
On Friday, September 2, 2011 4:11:19 PM UTC+2, Magno Machado wrote:
>
> Even if I use new instances for the requestfactory interface, transport,
> service layer and etc for each test, it would still share the services
> between one test and another?
>
Yes, because the cache is done in 'static'
Even if I use new instances for the requestfactory interface, transport,
service layer and etc for each test, it would still share the services
between one test and another?
On Fri, Sep 2, 2011 at 11:02 AM, StefanR wrote:
> Caching of services (which are mocks in such a scenario) is a problem
> i
Caching of services (which are mocks in such a scenario) is a problem
indeed. One easy solution on GWT side would be to have this cache
servlet-specific (i.e. ServiceLayer specific) and not as static field. I
worked around this by calling Mockito#reset() whenever the service
is acquired from my
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
I wrote a small tutorial about writing plain JRE unit tests for
RequestFactory classes. The basic idea is to use the request factory
infrastructure for entity conversion, etc. and replace the transport layer
with a "In memory transport". The backend service layer is mocked using
Mockito.
http:/
10 matches
Mail list logo
