Ex-colleague Pete Hodgson made a portal TodoBackend.com to showcase multiple server-side technologies for a TodoMVC app that he purloined from TodoMVC.com, that was about frontends not backends. He also wrote a JavaScript test harness for the server implementation (not purloined). Cool stuff.

I’ve talked about it before in More on technology compatibility kits in app development.

So one of those implementations, for a technology I’d never heard of before - Jooby - has a maven build, and some integration tests of its own (over and above Pete’s test harness). Maven gets a bad rap, and WebDriver suites people think should be slow, so I thought I’d take the solution and attempt to put quick WebDriver tests on top of it.

My fork of that ‘todobackend’ implementation - github.com/paul-hammant/todobackend-jooby - is the result.

Watch the build here, it is 20 seconds in this take, but it averages at 16 seconds.

It is a shame YouTube does not have a slow motion for the WebDriver phase.

There’s TWO processes involved in the solution’s autmated tests:

(well three including the ‘chromedriver’ executable that acts as a middleman)

And a sequence diagram view of the two processes:

Of note

  1. The browser window is kept open between tests. This is critical for speed
    • I’m using t0.devd.io thought T3.devd.io because they all map to 127.0.0.1 and this allows me to say there are no side effects between tests
  2. Jooby is launching the web server (Netty) itself during test setup, and it is staying up for the duration
  3. The WebDriver tests are testing JavaScript, HTML, and server-side Java - 3 tests in a couple of seconds (discounting t)
  4. The Backbone TodoMVC client app does not have its own build - it was just copied post-build into this solution, which many will claim artificially cuts down on the build time

Next Steps

Have a phase that mocks out (virtualizes the services of) the Java Server, and just tests the TodoMVC Js/HTML app on its own in the browser using WebDriver.

New era for Java Web applications.

With SparkJava, SpringBoot, Vert.x, Jooby and many others we are seeing the end of WAR file deployments to standalone Servlet containers (or larger still J2EE servers). Of course the Java community didn’t invent the style, they just took note of the advances in Ruby’s Sinatra framework and others.

It turns out that treating the web-enabling technology as a library and promoting terser scripting of them that are also XML free, appeals to developers. Looking back to servlets, JSP, and WAR file specs from 1996/7, we could say they were a disaster. These new technologies all use the main() method. They therefore have a primordial entry point for setup, and the back-flips we used to have to do between ‘listeners’, ‘servlets’ and ‘filters’ because we did not have one are now a thing of the past.

A Link to Jooby itself



blog comments powered by Disqus

Published

February 5th, 2017
Reads:

Categories