42¢ glxn.net

JSON Contract testing using unit tests to assert full stack integration across REST services

A while back I was faced with an interesting problem. The project I joined had an old-school web application consisting of JSP, tiles, Spring MVC, and a messy cluster of JavaScript. The functionality was all tested with Selenium. This kind of setup really makes me cringe. First off the JSP files often contain lots of logic, and are difficult to read, test, and debug. Secondly, there is often session state in the backend, which creates all sorts of headaches.

The cleanup

The main goal for me was to separate the frontend completely from the backend, and get the majority of tests running at as low a level as possible. This was achieved through the following steps.

Throw away JSP

No JSP files with logic, but instead a simple javascript app start hook which includes needed html through a templating system (e.g. _.template or knockout). This cleanly separated the markup from logic, and completely removes the need for rusty JSP files.

Ditch Spring MVC for REST

Remove all session state nastyness and set up new clean REST service endpoints. Now the

Move client logic into a structured javascript app

The possibilities here are pretty much endless. And the choice of which framework to use or even vanilla approach is up to you. I would focus on testability as one of the important factors in the decision.

I ended up with a mix of namespaced vanilla singleton pattern for the legacy stuff, and KnockoutJS for the newer stuff.

For testing I made use of Karma with Jasmine, which at the time was named Testacular. I can understand the renaming as googling for testacular often yielded results for something else completely.

Moving from selenium to contract unit tests

Now that the test framework was in place, and the logic was being tested in unit tests in Javascript and Java. I needed a way to guarantee that the frontend code would work with the backend code. The result was something I like to call contract tests. It is fairly simple to do. Simply create a set of JSON files and include them in your unit test suites. On the backend/Java side the contract is placed on the classpath, and unit tests assert that the objects serialize to and deserialize from the contract. On the client/javascript side the JSON files are included in the test suite using karma-html2js-preprocessor and tests assert that the view models and relevant javascript functions consume and produce according to the JSON contracts.

comments powered by Disqus

Moar stuffs

07 Jun 2015 Deploy an Ember app to gh-pages using npm run-script
06 Jun 2015 JSON Contract testing using unit tests to assert full stack integration across REST services
03 May 2015 simple http serve a directory from terminal
07 Jan 2014 civu, a CLI for cloning git repositories from jenkins views
06 Jan 2014 PyramidSort, a Sublime Text plugin for for reformatting text
05 Jan 2014 Git commit-message hook for JIRA issue tags
31 May 2013 hacking kitchen tiles with coffeescript
30 May 2013 Nuke, ps grep kill something
24 May 2013 mvnr: recursive mvn command runner
23 May 2013 Query By Example for JPA
22 May 2013 gitr: recursive git command runner
21 May 2013 Keeping gh-pages branch in sync with master
19 May 2013 Migrated from wordpress to jekyll and github pages
14 Aug 2012 Using Sublime Text 2 as git commit message editor
10 Mar 2012 QRGen, a small wrapper on top of ZXING for generating QRCodes in java
04 Jan 2012 My Bash PS1 with git branch info
17 Aug 2010 Making a swing project using IntelliJ IDEA GUI builder with maven, Including executable jar
01 May 2010 Using Arquillian to test against a remote jboss container from within IDEA
06 Apr 2010 WELD/CDI lightningtalk from Know IT 2010 annual conference
03 Apr 2010 Solving Sudoku using java swing and junit
01 Mar 2010 Simple CDI/WELD login example
01 Mar 2010 Implementing @RequestParam in CDI/WELD using Qualifier and InjectionPoint as @HttpParam
01 Nov 2009 Seam Maven Refimpl