On Monday, May 20, 2013 2:14:42 PM UTC-4, Goktug Gokdogan wrote:
>
>
>
> On Mon, May 20, 2013 at 6:42 AM, Thad <thad.hu...@gmail.com
> <javascript:>>wrote:
>
>> Can anyone clarify for me this Google testing blog entry?
>> http://googletesting.blogspot.com/2009/08/tott-testing-gwt-without-gwttest.html
>>
>> Model, view, presenter I think I'm clear on (ha! yeah, sure), but I'm
>> trying to understand the Server.class. It's described as "a completely
>> standard backend with *no dependency on GWT*." (Their emphasis.) So what
>> is that? Does that mean *not* a service interface and *not* a service
>> Impl class? If so, where is the RPC coming in?
>>
>>
> That is the Async interface. Technically, it still depends on GWT for the
> AsyncCallback interface.
> I think what they actually meant is, it doesn't depend on any native
> methods so it is easy to mock.
>
>
>> What I'm trying to do--what I think many would like to do--is test RPC
>> methods without the RPC delay. Right now I do that by calling my
>> ServiceImpl methods in my JUnit test. This often forces me to mock an
>> HttpSession object and add an extra method so I can pass that in
>> (since getThreadLocalRequest() is protected). Testing through my client
>> would be preferable but the delay is a pain.
>>
>
>
> Refactor your service out of your servlet. A common useful pattern is:
>
> class ServerServlet extends RemoteServiceServlet implements ServerService {
> ServerServiceImpl service = ....
>
> public void someServerMethod() {
> service.someServerMethod();
> }
> }
> class ServerServiceImpl implements ServerService {
> // implement your logic here
> }
>
> Then write the test against for ServerServiceImpl which doesn't depend on
> any servlet internals. Note that, this is pattern also useful if you need
> to call ServerService at server side in production.
>
Is that safe? My services makes heavy use of the HttpSession. At a minimum,
I store the user's connection to the legacy server app I work with, but
there are other things, too--tables last queried, images retrieved, etc.
This is why I wish I could override getThreadLocalRequest() with a mock for
testing.
To have an entirely separate class, I'd have to instantiate it with each
RPC call so the session object wouldn't get stomped on by another user. I'm
worried about that overhead once I'm out of development and test and into
production. Failing that I could pass the session in with the call, but
then I don't see the point of a separate class. I could just have something
like this for each public method.
@Override
public LoginInfo doLogin(String server, String name, String passwd) {
return doLogin(getThreadLocalRequest().getSession(true), server, name,
password);
}
private LoginInfo doLogin(HttpSession session, String server, String name,
String passwd) {
MyApp app = new MyApp();
// prep more params and log in
...
app.login(server, name, passwd, param0...);
// remember session
...
return app.getLoginInfo();
}
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
