Login

Java

General purpose programming language.

Testing the Java REST-MVC Server Tier

Article Summary
This article is part of a series. We use the "book club" project to explore various programming languages and frameworks. Details of the book club's business and data requirements are detailed in a prior article, "Leveraging Ruby on Rails and ClojureScript.".

We've created a new version of the book club's server tier using a stack of Java components. See the article REST-MVC using Java for details of implementation. This article details automated testing for the Java/REST-MVC server tier.

Automated Unit Tests
In this article we will not enforce a strict differentiation between "Unit" and "Integration" test.

This article refers to "automated testing". That means, the programmer writes a separate program(s) to "test" functionality. We use the Junit testing framework along with some plugin/extensions (Mockito, JsonPath and Hamcrest).

Organizing Tests Into A Plan
In this section of the article we discuss "what" we test.

We need to consider the business and functional requirements of our application and then plan our test suite. So, let's recap our application and organize our test plan. We have entities (and a relationship). Entities are Authors, Books, Categories and Reviews. Book-Categories are relationship between a book and a category (E.G. Tom Sawyer is Fiction).

We also have application services.

  • A repository is responsible for reading and writing data, to and from the database (and the application data objects).
  • A controller accepts requests, dispatches the request to a handler, then routes the response. Our server has 2 types of controllers. We have controllers which route the response to server generated view (E.G. jsp/html/css). We also have controller which generate a JSON response (the client renders the view).

Finally, our application has some specific implementation/optimization requirements. We require the database (as opposed to the application code) enforce unique Authors, Books, Categories and Book-Categories. We require the database to delete related records. For example, books require an author. If we delete an author, the database should automatically delete all of the books written by that author.

So here are the "operation/method" tests:

  • Select records
  • Insert a record
  • Modify a record
  • Delete a record
  • Attempt to insert a duplicate record.
  • Attempt to modify an existing into a duplicate.
  • Delete an Author and verify all related books, reviews and book-categories are also deleted.
  • Delete a Book and verify all related reviews and book-categories are also deleted.

For each of the above we perform for the following services:

  • Repository
  • Controller
  • Rest Controller

For each service, we test the following entities :

  • Author
  • Book
  • Category
  • Review

For each service, we test the following relationship :

  • Book-Category

REST-MVC using Java

Article Overview

This article is part of a series. We use the "book club" project to explore various programming languages and frameworks. Details of the book club's business and data requirements are detailed in a prior article, "Leveraging Ruby on Rails and ClojureScript.".

This article details a new server tier implementation. We employ a stack of Java libraries and tools. Source code and build files are located on GitHub, at the book-site-jpa repository.

Server Tier Software Stack

Spring

Spring was originally designed as a lightweight alternative to J2EE. Thus, Spring provides the "big picture" benefits of J2EE. In particular, you can change your application components via Spring's configuration (I.E. instead of changing your application's source code).

Let's look at the historical perspective before going to some of Spring's details.

J2EE was designed for large applications and large organizations. Hence the term "enterprise". When J2EE was first introduced, it defined several development roles within an organization (see Chapter 3 - Applying Enterprise JavaBeans). An "application assembler", "deployer" and "system administrator" combined to serve as a "application server administrator". A role, or group, who's responsibility is similar to a database administrator (DBA). Instead of administering a database, these developers focus on solving an application's business logic by configuring the J2EE components and settings.

Managing Spring's configuration is much simple than the original J2EE specification. The latest J2EE specification has adopted much of it's simplifications from Spring.

Annotation versus XML configuration settings.

Actually, I shouldn't use the word "versus". Almost all of Spring's settings can be now performed through annotations. In addition, you can use both XML and annotated settings together. If your shop is large enough to have a dedicated "application server administrator", you may prefer to keep settings in XML files. XML files are external to the Java source code files. Thus, an "administrator" can tweak the application without touch the source (when settings stored in XML). Vice versa. If your shop combines development with operations, then you may prefer storing settings in an annotated form.

Note! The same is true for other components of our stack (Hibernate, Jersey, JPA, etc). We can define setting in both annotations and XML.

Data Persistence

We'll use Hibernate to provide a transaction manager and map our database schema to Java objects. Java Persistence API (JPA) adds a vendor agnostic API on top of Hibernate.

Spring allows us to annotate all the services together. Spring allows us to inject transacation manager services and JPA repositories (classes which provide basic CRUD functionality).

H2 Database Engine

We use the H2 Database engine in "server mode" as our system database. H2 is very lightweight and easy to set up.

Business Logic

Spring MVC provides a framework for our business logic. We locate most of business logic in Spring Controllers.

Views
Spring's MVC provides a framework for many different types of views. For the book club, we are using web page views (SPRING MVC + JSP/HTML/CSS etc.). Most of the web page artifacts are generated by the server dynamically.

Note! We also implement web pages which are generated dynamically by the web browser (client). We implement a set of Spring Controllers which communicate via JSON with a RESTful interface. See "Jersey JAX-RS/JSON" below.

Web Server - Servlet Engine

For the book club, we are using Jetty as our Web server and servlet engine. Specifically version 9.0.4 of Jetty.

CSS Framework

We also use the Pure CSS framework to layout the web page views.

Jersey JAX-RS/JSON

We use Jersey JAX-RS to ready JSON data sent by our Clojurescript client. We also use Jersey to provide a JSON representation of Java objects when preparing a response (to the client).

Rapid Development in Java

A few folks asked me how I built the mobile version of this website. Thus, I wanted to describe the process in this article.

Background and Goals
My current website (Public-Action.org) is built with the PHP content manage system (CMS) Drupal. I could add new functionality to the Drupal CMS. However, I thought this would be good chance to extend some of my other skills.

I decided to generate a new mobile view-able version of my web content using Java. That gives me an opportunity to explore some of the newer computer languages which run on Java Virtual Machine (JVM). For example, Clojure or Scala.

A lot of shops have a large inventory of business requirements implemented in Java. To me. Java is still relevant as a computer language. However, newer programmers tend to be versed in other computer languages. Thus, an exploration of extending our basic process with a newer computer language seems worthy.

In this article. we'll produce the basic functionality used to create to exiting mobile version (view-able) of this site (public-action.org).

Building the mobile version of our website.
Our current website generates a Rich Site Summary (RSS) feed. RSS in an xml representation of the sites content. The current site's layout design is built to render on a full size (desktop/laptop) web browser. The site's layout is defined by the domain specific language (DSL), Cascading Style Sheets (CSS).

Thus, we need to replace the current CSS with CSS that responds and re-sizes to fit a mobile device. Again, we will use the responsive layout and design provided by the Twitter Bootstrap Front-end Framework.

Process Overview
I don't want a completely automated process. I want to manually inspect and verify the new mobile content (site) before publishing.

I need to get the mobile site up and running as soon as possible. That allows me to field test the site. My experience is, for mobile content, you literally need to take a walk with your device and see what your content looks like, how it renders when you are on the road.

Thus, we will rapidly prototype and build this application. I don't need a lot of bells and whistles. A plain command line utility fits my needs.

Syndicate content