Manual Dependency Injection with Jersey and embedded Jetty

I wrote a little application demonstrating how to manually (through constructors) inject dependencies into Jersey resources in an embedded container like Jetty. 

The benefits are:

- lightweightness (no need to use Spring, Guice, etc.),

- more control over your application (less magic behind the scenes),

- controlling dependencies in tests (via Dependency Injection)

- running a web app with a simple Java main method (via embedded Jetty)

The example application is called Time Expert. It exposes the current time via a RESTful web service, so when I run it in the production (via Main.java) I can use it as following:

Here's how I test it (TimeAcceptanceTest.java) :

However,  I cannot rely here on the real time because it changes every time I run tests . The problem can be easily solved with the Clock pattern. My tests require a FixedClock which allows me to set the current time to any value:

 So I start my server with a fixed clock:

... and then set it to, say, 20:15:

Since my Jersey resource class is only aware of the clock interface, it will display 20:15:

In order to create your Jersey resources with manually injected dependencies you have to register org.glassfish.jersey.servlet.ServletContainer with a customized org.glassfish.jersey.server.ResourceConfig. In that config Jersey resources can be newed up with their dependencies:

Of course the production provides a real clock (which returns new Date()):

Code is available under: https://github.com/unclejamal/TimeMaster

Enjoy!

Tested using:

- Java 1.7,

- Gradle 1.7 (easily convertible to Maven :)),

- Jersey 2.2,

- Jetty 9.0.5.

BDD with Robot Framework and Java

Inspired by Matt Wynne's podcast "BDD as it's meant to be done" I reproduced his sample application with usage of Robot Framework and Java (in place of Cucumber and Ruby). This post is intented to give an overview of a possible setup for Java-based BDD (source code).

Idea

According to Gojko Adzic, 90% of teams that fail with ATDD don't structure they tests properly which results in so called scripts (dozens of test code lines which mix up specification, workflow, user interface) that are a extremly difficult to mantain. The tests should answer the question 'what' to test as opposed to 'how' to do it.

Matt suggests to structure acceptance tests in a layered stack (I rephrased the layer names):

• Examples - table-based set of input values introduced to the system and expected output values upon performing some action
• Scenario - Given-When-Then style of describing the action from Examples step-by-step
• Steps - detailed definition of Scenario steps kept in an technology-independent manner
• Glue - glue code connecting tests with the app itself (uses domain or interface classes in order to manipulate the Application)
• Application - the application itself (should work according to the Examples)

Benefits:

• Examples & Scenario layers clearly communicate the specification to Anybody (Customers could even modify it themselves)
• Steps layer is actually a DSL (Domain-Specific Language) of the application. Exploring it creates a common domain-based language for Team Members and Customers. Further, it allows to execute the same set of tests via different interfaces implemented in the Glue layer
• Glue layer drives us to create testeable classes and methods in the Application
• Turns test (a.k.a. specification) writing into a creative and useful activity

Sample application driven by Robot Framework

Source code is available under: https://github.com/unclejamal/CashDispenser

Prerequisites: Java 1.6, Maven 3.x, Robot Framework 2.6+ (this is the setup I tested it with)

Building:

mvn clean install

Testing

cd atdd/cashdispenser-robot/target/
test.bat

Test logs will be created in:

atdd/cashdispenser-robot/target/output

Nice-to-haves and what-nots

In Java EE it would be nice to create two Glue layer implementations. First, that manipulates directly Java classes and uses test doubles to be separated from external services (this could be run after every single build). Second, that uses Jython to execute EJB public methods directly in the container (this is much slower, but permits a more end-to-end testing).

Finally, to see a hands-on example of BDD with Cucumber and Ruby, I strongly recommend watching Matt Wynne's podcast "BDD as it's meant to be done".