JSON vs GWT-RPC - Unit testing and manual testing for a newbie

[Andy_W]

Hi,

I am trying to decide whether to use GWT-RPC or JSON for a new
project. We are using a full Java stack (Spring, Hibernate etc), so
most people would say it's a no brainer to use RPC. However, one of
things I did like about JSON was being able to hit a URL, without
loading up the UI, and then verifying the simple JSON string that came
back. This saves time if the UI is very complex and takes a good while
to load up. Is there any way to do this with GWT-RPC, or does the UI
need to be loaded up for testing?

Finally, is it possible to make "client side" unit tests with JSON
that extend GWTTestCase, or is this for RPC only?

Many thanks for any input.

[Y2i]

For full Java stack RequestFactory may be another option for a new project.

http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.html

[Thomas Broyer]

Not to mention that you can do "in process" unit-testing with RequestFactory, which is very helpful! (this also means you can build a RequestFactory client in a few lines of pure-Java code, you'd just have to code and provide an appropriate RequestTransport to reach your servlet)

[Ryan Mehregan]

If you decided to go with REST-like architecture,
exchanging JSON encoded data, there are some resources
that can either make the job easier for you, or be source of
inspiration.

make sure to also checkout AutoBean
http://code.google.com/p/google-web-toolkit/wiki/AutoBean

GWT-REST
http://code.google.com/p/gwt-gae-book/wiki/GWTREST

Resty-GWT:
http://restygwt.fusesource.org/

GWT-JSON-CommandPattern,
http://code.google.com/p/gwt-json-commandpattern/

Piriti
http://code.google.com/p/piriti/

interesting discussion on how to use REST with GWT can be found on
this thread:
http://groups.google.com/group/gwt-platform/browse_thread/thread/39bbc24842168f6a


Ryan

[Ryan Mehregan]

some useful resources on RequestFactory:

GWT Documentation:
http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.html

excellent source of GWT related articles
http://tbroyer.posterous.com/

in-progress sample project
http://code.google.com/p/listwidget/

[Ryan Mehregan]

with GWT 2.1, there is another client-server communication mechanism
called RequestFactory.
RequestFactory uses JSON behind the scene, and aggressively caches
data,
when your data model changes, RequestFactory only sends the changed
bits over the wire, not the entire object graph;
Which results in improved performance.
RequestFactory also has a Service Layer which makes it easy to
integrate with thir-party frameworks including Spring.

RequestFactory is in charge of getting data to and from server,
once your data reaches the server, RequestFactory can hand the data
over to Spring,
so that Spring Service layer can take charge.
When You want to send data to the client, You hand in your data to
RequestFactory and RF sends it to the Client.


if you are starting a new project, I believe its worth looking into
RequestFactory.
RPC has been critisized for having a bit of overhead, in terms of
payload and a bit slow.
RequestFactory is where the GWT client-server communication is headed,
especially for data-oriented applications.

[Ryan Mehregan]

RequestFactory comes with some helper classes that
allow you to run your tests within the JRE environment,
which means your tests are executed in miliseconds.

http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/requestfactory/server/testing/RequestFactoryMagic.java

[Jeff Larsen]

Thomas, How hard would it be to change the RequestTransport to use a less obfuscated JSON, standard jackson JSON payload?

I'm curious because I am currently tasked with writing a framework that needs to be server agnostic. I'd gladly sacrifice some of the speed and transport efficiency for a pure JSON encoded object. I've poked around at the code a little bit, but it is easy to get lost in there.

[Thomas Broyer]

The RequestTransport is given the already-JSON-encoded payload as a String, so unless you parse it to re-serialize it as a "different JSON" (and doing the same on the server side in e.g. a servlet filter) I doubt it's possible.

The JSON payload is not "that" obfuscated though. It's entirely based on AutoBeans itself, and the messages are described at http://code.google.com/p/google-web-toolkit/source/browse/tags/2.1.1/user/src/com/google/gwt/requestfactory/shared/messages/

FYI (and IIUC), a "synthetic" ID is used for ValueProxy-s, while EntityProxy-s use either an "ephemeral" ID (when the object has been created on the client-side) or a "persisted" id (if it exists and is considered persisted on the server-side). ValueProxy-s use IDs so that the payload can use graphs of objects (AFAICT), where the same ValueProxy is used several times in the request. And every time you see a "Splittable", it's a JSON-encoded value as a String.

I'm pretty sure the format could change a bit in future releases though (I expect it to not change much though, to ease deployment of new versions of apps). Someone from Google could tell you.

[Andy_W]

Ok Thanks for all your replies, but this has confused me even more. I
don't really want to introduce even more new technologies to learn
over and above GWT and JSON. Can you test serverside code using GWT-
RPC just by hitting a url like you can when using JSON?

[Thomas Broyer]

On Tuesday, January 18, 2011 3:51:36 PM UTC+1, Andy_W wrote:

Ok Thanks for all your replies, but this has confused me even more. I
don't really want to introduce even more new technologies to learn
over and above GWT and JSON. Can you test serverside code using GWT-
RPC just by hitting a url like you can when using JSON?

Short answer: no.

Long answer: it shouldn't matter, because what you want is that the service behaves as expected. It doesn't matter how the returned value is serialized because you don't control the serialization process. What I mean is that you should unit-test your service to check it's behavior, and if you want to do integration testing (does it still behave as expected once deployed and connected to the real database, etc.) then you can use things like http://code.google.com/p/gwt-syncproxy/ for GWT-RPC, or RequestFactoryMagic for RequestFactory.

[pete]

I just used Guice + Gin + Mockito and found this very productive for
writing well tested code. Especially if you apply MVP on the client-
side, you can unit test your client logic rapidly / test-drive with
normal JUnit / TestNG.
I used RPC and just mocked out the AsyncCalls using Mockito,
simulating that certain Callbacks arrive.
Then you can just test your client side, make different scenarios,
suppose Object Blah is returned by AsyncCallback.onSuccess(Object obj)
and so on.
On the server side you can use Guice to decouple the actual
servicesImpl completely from the RPC-mechanism. Then your server
classes only need to implement the synchronous client interface, not
RemoteServiceServlet anymore.
So you can easily test all your server-side logic like normal java
classes, can check that if the client sends this and that RPC request
(meaning this and that request objects), that the service method
really does what it is supposed to, and gives back the correct values.

If you're interested in this, here are some links:

Guice:
http://code.google.com/docreader/#p=google-guice&s=google-guice&t=UsersGuide

Gin:
http://code.google.com/p/google-gin/

Mockito:
http://mockito.org/

How to mock AsyncCalls with Mockito (Example):
http://blog.reflectedcircle.co.uk/?p=162

How to use Guice for decoupling RPC-Services (Example):
http://stuffthathappens.com/blog/2009/09/14/guice-with-gwt/

If you use this, you can make sure, that the correct RPC-objects are
returned on simulated calls without ever sending real requests over
the wire or to specific URLs...