I am also in the process of making GWT-RPC method implementation
independent of GWT-RPC/Servlet for easier testing. I don't really bother
about introducing new short lived objects created for each request. Short
living objects are not a real problem in todays JVMs and you can probably
save a lot more resources by optimizing heavy weight algorithms, etc. But
as always: Only start optimizing if you have to because some service is too
slow or consumes too much resources. As long as everything works fine just
write clear, easy to understand code.
So in case of GWT-RPC + command pattern you maybe end up with something
like:
public Result execute(Command cmd) {
HttpSession session = getThreadLocalRequest().getSession();
//HttpSession needs to be mocked or stubbed
Cache cache = new SessionBackedCache(session);
//following code does not know anything about servlets and GWT-RPC
CommandDispatcher dispatcher = new DefaultCommandDispatcher();
CommandExecutor executor = new DefaultCommandExecutor(cache, dispatcher);
Result result = executor.execute(cmd);
return result;
}
With this code you can unit test SessionBackedCache,
DefaultCommandDispatcher, DefaultCommandExecutor and then I would think
twice if I would write a test case for the GWT-RPC method itself as its
implementation is super simple. When using an injection library like
google-guice this code would probably be even shorter.
If I could avoid it, I would never delegate to a private method, like in
your example code, and then make this private method accessible again using
reflection during tests. IMHO tests should cover public methods and not
private ones.
-- J.
--
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 [email protected].
To post to this group, send email to [email protected].
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.
