Testing my RESTful controllers with Spring RESTtemplate

I have been playing with Spring's RESTtemplate as an approach to integration testing on my project.

Overview of Testing a RIA with Spring and Spring MVC

I feel I should create a set of blog posts related to how I am doing testing with this technology stack. Sometimes this aggregation is helpful. In my team, we are testing at the following levels:

• unit testing of everyting - pure tests, typically single class only, with mock (using Mockito)
• integration testing of our services - out of container (web server) testing, but with db
• integration testing of our controllers - in container testing, with db
• functional testing of our ui (TBD) - full in container testing

This blog will focus on integration testing.

Integration testing, different from unit testing, tests the code as it is wired up to other components, the server and the data base as well.

Testing the controller layer in Spring MVC

To set the stage, I am using spring 3 with Spring MVC for my application. In particular, I am leveraging a lot of Ajax, accessing the controller from the browser and transporting JSON. I am using the Jackson JSON mapping implementation to marshal to from beans to JSON.

I need to create good integration tests of my controller classes so I can run JUnit tests that connect with the deployed web app and interact RESTfully like the client UI, passing JSON objects back and forth.

A helpful blog post I have used for guidance: is ralf.schaeftlein s blog detailing an approach to integration testing of restful MVC controllers with JSON. Exactly what I was interested in.
The basic steps seem to be:

1. create a unit test with java4 leveraging Spring 3 Integration Test Annotations
2. configure your application context XML to define your mappers that will convert between JSON and beans
3. write your tests pojo style

Integration Testing with Spring uses annotations to supply a spring context to your test code. Further, the annotations specify what transaction manager to use and if a rollback should be performed after the test is complete. The tests itself are written with JUnit4. Here is a snippet showing the annotations required placed on your test class.


In this case, I am testing my Data Repository, which is essentially my Data Access Object (DAO) for you old schoolers. I will post why Repositories and not DAO in a future blog.
My application context file configures spring with the required setup for my application to run this test. First, the usual name spaces:

Then, we use automatic annotation discovery of out project

Here is wshere we configure the restTemplate to be used for this integration test of our controller
Finally the required configuration for our persistence. Notice we are using JPA configuration here


Finnaly the test code.

We write an integration test for our controller that connects remotely to the deployed application, sends beans mapped from Pojo to json for the call, and then maps back json to Pojo to assert results.

A shout out to a framework for html5

One of my readers sent me a link to Strobe, (http://www.strobecorp.com/) an open source platform built from the ground up to leverage html5, but still leverage MVC. Although my ship has already left down the river of Spring, I can longingly look at its innovation and see what we can adopt for ourselves. I know I will loose a few hours this weekend on playing with this one.

Thanks

PS, I also seem to be wasting my time playing with knew language ides: ever check out Clojure. Yes, it talks with a lisp as well.

Crossing the chasm to the new paradigm

I titled this post in homage to Moore, the author of Crossing the Chasm. He clearly described how marketing strategies for high-tech are different from other product categories. He heavily leverages the technology adoption life-cycle bell curve where Rogers et. al. segments people into 5 categories:

1. innovators,
2. early adopters,
3. early majority,
4. late majority and
5. laggards

(although the last category seems a bit offensive :)). Moore emphasizes that getting from early adopter to early majority is like crossing a chasm: the former 'visionaries' have very different expectations then the later 'pragmatists'. To mix authors (like metaphors), a 'tipping point' seems to be required to make the shift.
So it is for developers: new ideas, languages and techniques come by all the time. Some jump in 'where angels dare to tread'. I seem to be the former. At least I like to think of myself as such. Others wait. Some are clearly risk averse, but I think for some, it is hard to let go of the 'it works, why change it' paradigm. Perhaps they are right. They are pragmatists, and by nature practical. But innovators and early adopters seem to reap benefits. Since the technology wave moves incesntly and swiftly, it is best to keep on its cusp, like a surfer, using its power and momentum to guide you on, lest you be left paddling to catch up, far behind.
But many on my team aren't of the innovator ilk. Nor is my company. I work for a very large software company that should be on the leading edge, if not the bleeding edge of innovation adoption. But we're not. We suffer from a stifling bureaucracy (like most large companies or governments, dare I say), and a hefty dose of 'not built here' syndrome. Interestingly enough, by boss isn't a 'laggard' in any stretch of the imagination. He, however, bears the brunt of having to argue for the wacky ideas of his reports in front of very risk averse corporate gatekeepers. Sometimes he wins, sometimes not.
But, within the team, it was surprising to me how shocked people were when I said,

"we are not going to write JSP any more."

I'm sure some of the readers of this blog post (all 1 of you) might be shocked as well. But sometimes we need to be shocked. This is a broad and sweeping statement, but it is powerful, because it hints at our reliance on rendering the UI on the server. And we shouldn't. This is heresy, and would have been foolish in the past. From early cgi and perl (remember those days) to the development of J2EE, the browser was considered a dumb reader of html, not a smart client platform like thick client apps or client server. Applets were to be that, not the browser. If not Applets, then flash, if not flash then... well, ... the browser.
What is the browser today? Its not dumb. It's not just a reader. It is an operating system. It is a platform that has capabilities to run sophisticated programs delivered to it. HTML5, CSS3 and JavaScript are the languages it speaks. If you know the lingo, you can unleash a vast array of capabilities that just a couple of years before were left to the native or thick client world.
So, my aha moment came when I realized that what we needed to do was to go back to the client server days. In those days, you had vast power of the desktop, its graphical and multimedia power and local storage capability. You connected to the server for data. Yes, business rules and shaping of data occurred on the server. Certainly secure selection and delivery of data as well. It enforces transactionality and validity. It handles persistence and auditing. But its is never in the business of rendering the user interface--that's the client's job.
Rendering UI on the server was the compromise required to deliver applications over the web. And it was worth it too. Not to wory about the client footprint, not to have to wait for support to install and configure the next version. immediate access to everything a mouse click away. It rocked our world. It changed our world. Thanks Tim for that. But he was thinking hyperlinked books after all, not applications. It was amazing what we can do even with its obvious limitations. And Tim has moved on too.

But we no longer need to make this compromise. We can benefit from the zero footprint immediate access to all the worlds knowledge and applications but still leverage graphics, multimedia, processing power and even local storage of the desktop.

Fun with HTML5

I guess I'm a bit late to the game. However, perhaps not too late. HTML5 offers a host of solutions for the kind of application I want to build: rich client, local storage, animated, etc. I walked through several HTML5 demos and examples over the weekend.

I can deliver a rich client experience for an application needing local only storage with nothing but HTML5, JavaScript and CSS3. But for real 'client server' or mashups with shared information, we still need connectivity to the server (Ajax based, RESTful, transport in JSON).

New Technology Stack

In my real life, I actually have to deliver software :). So most of my blogs are about the technologies I am using today as well as best practices I am actually practicing (or trying to practice) in my real life.

This blog will focus on the following technology stack for now:

• JQuery and JQuery UI
• Spring and Spring MVC
• Java Persistence API (JPA 2.0)

Also I will be looking at:

• Spring Roo
• and GWT (Google Web Toolkit)

Some techniques and tools include

• Sun NetBeans IDE
• SpringSource Tool Suite
• Test Driven Development
• Continuous Integration
• Maven

Back again and focusing on Enterprise 2.0

Why did I rename this blog Enterprise 2.0 Appplication Tecchnologies?

I am not abandoning ECM and SOA, but I am expanding to incorporate a more generalized concern.

To me, enterprise 2.0 is bringing the promise of web 2.0 to enterprise applications. Not just in providing a better social experience, but providing a better user experience in general, with more user centered and natural user interfaces.

Since Sun quoted "the network is the computer", many (myself included) have been trying to find a way to build enterprise applications that have a rich client experience but are not locked into a heavy installation footprint. Conventional web development has allowed us to build Software as a Service (SaaS), minimizing client and installation requirements and maximizing availability. But on the other hand, these applications are typically designed for the least-common-denominator, heavy on server side processing, have very unnatural user experiences, are constructed with a cacophony of languages, and tend to be a slave to bandwidth and availability of the network.

An ignorant corporate sponsor might ask "Why can't we have the rich user experience of the desktop while leveraging the ubiquity of the web?"

Well, now we can. Through the power of JavaScript and HTML5 the browser can support truly rich client experiences, while still leveraging the advantages of the web and being available anytime, anywhere on any device. Constructing access to information and actions using the power of REST and semantic net, different user experiences can be developed to share and leverage the knowledge of the enterprise in different ways. And still the enterprise applications can leverage well tested legacy services, be secure and achieve the availability and performance requirements demanded by the corporation.

However, I am still concerned with requiring constant connectivity. Most of even the best internet applications that deal with transitional data require continuous high bandwidth connectivity to the services. Especially for the mobile worker (an ever increrasing demographic), being able to work 'off-line' sometimes is essential.

So, my search for the answer to the question "Why can't we have the rich user experience of the desktop while leveraging the ubiquity of the web?" includes the following:

• Rich client experience supporting many user types and many devices, including the use of graphics, multimedia and alternate input technologies
• Secure access to semantically rich resources and services that are flexible and can be leveraged from many different clients
• Connectivity to other legacy systems and services, supporting synchronous and asynchronous models
• Mechanisms that allow users to share and collaborate and work off-line as well as on line

We want secure access to corporation's transactional information and services available at any time, from anywhere on any device, while allowing users to organize their own experiences and collaborate with others the way they want to.

The purpose of this blog is to try to address these concerns and others through technology available today, relevant to my own direct work requirements as well as the purely theoretical.

Moving On

I am shifting my focus in my career from Enterprise Content Management with Service Oriented Architectures to more Service Oriented Architectures and Rich Internet Application development. I will be focusing on the Oracle Fusion Middleware stack, not Alfresco, jBPM and ServiceMix. I will be developing applications using Oracle JDeveloper tools with Oracle's Application Development Framework (ADF).

So, I will continue to use this blog, but I will be shifting articles to talk about these technologies.