Android: Unit Testing Apps with Couchbase, Robolectric and Dagger


This Android / Gradle project on GitHub shows how to integrate Couchbase, Robolectric and Dagger so that unit testing can occur without the need for a connected device or emulator.

Background

I need a database for my TripComputer app so that users can keep a log of their Journeys. I could use SQL Lite, but I prefer not to use SQL if possible. With SQL you’re forced to maintain a fixed schema and SQL Lite doesn’t offer any out of the box cloud replication capabilities, unlike most NoSQL databases.

Couchbase Lite for Android is an exciting new embedded NoSQL database, but because its ‘Database’ and ‘Manager’ classes are Final and require native code, it’s not trivial to mock them or integrate them into apps that utilise the popular Robolectric testing framework.

Therefore, in order to support off-device Java VM based testing with Robolectric it is necessary to write custom interfaces and use a dependency injection framework that will allow the injection of mock objects to occur when testing. To achieve this ‘dependency injection’ of mocks, I’ve used Mockito and introduced the Dagger framework into the code.

Software Versions

  1. Couchbase-lite 1.0.3.1
  2. Robolectric 2.4
  3. Dagger 1.2.2
  4. Mockito 1.10.19
  5. Android Studio 1.1 Beta 3 (optional)

About The Sample App

The App I’ve built here is very simple. When the user clicks the Save button on the screen, in the background a new document (technically a `java.util.Map`) is created and saved to the embedded Couchbase NoSQL database. While saving the new document, Couchbase automatically assigns it an ID and it is this ID that is ultimately displayed to the user on the screen after they’ve clicked the Save button. The document id’s in Couchbase take the form of GUID’s.

The App Code

Roughly speaking, in the `app` codebase you’ll see the following…

1. `MyActivity.java` is a simple Android action bar activity that extends a `BaseActivity` and requires a `PersistanceManager` to be injected at runtime so it can talk to the database.

2. `PersisitanceManager.java` is a class that acts as a DAO object to `MyActivity`, managing the persistence of ‘Map’ objects. It offers only INSERT and GET operations in this sample and requires a `PersistanceAdapter` implementation to be injected into it.

3. `PersistanceAdapter.java` is an interface that defines INSERT and GET operations on `Map` objects. This interface is required later when mocking & testing.

4. `CouchbasePersistanceAdapter.java` is a concrete implementation of the `PersistanceAdapter` interface. It utilises Couchbase and depends on a couchbase `Database` object which must be constructed by Dagger and injected into it.

5. The injectable objects that require non-trivial instantiation (like the Couchbase `Database` object for example) are defined by `@Provides` methods in a Dagger `@Module` in the `MyActivityModule` class.

At runtime, Dagger, `MyActivity`, `BaseActivity` and the `App` application classes take care of constructing an `ObjectGraph` for the application and inserting the required dependencies so that all the various `@Inject` requirements can be met. The “Instrumentation (integration) Tests” in the Android App gradle project test that this integration and dependency injection is working as expected.

The Robolectric Tests

Because it’s also desirable to perform testing without a device or emulator, there’s a set of Robolectric tests for the App’s `MyActivity` class that test the same ‘Save’ feature but without the need for a connected or emulated device and without the need for an embedded Couchbase database.

In the `app-test` gradle project you’ll see the following…

1. `MyTestActivity.java` extends the MyActivity class and `@Overrides` the `getModules()` method. This method constructs and returns a `TestMyActivityModule` instance. `TestMyActivityModule` is an inner class which defines an alternative (overriding) Dagger `@Module` that can also provide a `PersistanceManager` for injection into the `MyTestActivity` when testing. This module `@Provides` a fake, programmable `PersistenceManager` _mock_, not a real persistance manager as is expected under normal conditions.

2. `MyActivityRobolectricTest.java` is a standard Robolectric test, but it’s Robolectric controller builds a new `MyTestActivity`. The method `testClickingSaveButtonSavesMapAndDisplaysId()` tests that clicking the _Save_ button has the required affect by pre-programming the `PersistenceManager` mock with behaviours and then verifying that this mock has indeed been called by the Activity as expected.

Running the Sample

To run the tests for yourself just clone or download this repository and then execute the following gradle commands. For completeness, I’ve included some Android Instrumentation Tests as well and you can run them with `gradlew connectedCheck` (assuming an emulator or device is present).

gradlew clean
gradlew assemble
gradlew check
gradlew connectedCheck (this is optional and assumes a device is present)

Acknowledgements

Many thanks to Andy Dennie for his Dagger examples on GitHub. These were really helpful to this Dagger noob when trying to understand how to integrate Dagger with Android.

About the Author

Ben Wilcock is the developer of TripComputer, the only distance tracking app for Android with a battery-saving LOW POWER mode. It’s perfect for cyclists, runners, walkers, hand-gliders, pilots and drivers. It’s free! Download it from the Google Play Store now:- Get the App on Google Play

You can connect with Ben via his Blog, Website, Twitter or LinkedIn.

Announcing: Trip Computer for Android


The reason that I’ve been so bad a posting recently is that I caught the Android development bug. I’ve been using all my spare time working on a new Android application called ‘Trip Computer’.

Trip Computer is a cost and distance tracker that you can use to help with business mileage expenses, or for leisure any time you want to know how far you’ve travelled, which direction you’ve been going in or how long you’ve been going. You can use it walking, cycling, running, in the car, on the train or even on boats or planes (subject to the usual flight restrictions).

TripComputer-app-framed-shadow

Working with Android has been the most brilliant experience, it really is very cool. I’ve also been exclusively using the new Android Studio IDE from Google (pre-beta) including it’s built in Gradle build system.

Android Studio is really good. Announced at last years Google I/O conference it’s based on IntelliJ Idea Community Edition and already it’s giving Eclipse a real run for its money with its strong integration into the Android eco-system. The learning curve has been quite forgiving and the IDE quality and stability are very surprising considering its not a fully released product.

Gradle is a different story. I can take it or leave it to be honest. As a Maven user, I can see lots of issues and nasty cludges (like the poor file ‘filter’ and replace experience which is really useful and much better in Maven). The learning curve has been steep, possibly because Android projects are not standard Java projects. But no pain no gain as they say and I do feel like I’ve come out the other side stronger and more flexible as a result.

I did pick up some handy Android hints and tips along the way, which no doubt I’ll share when I get more time.

You can download the full app for free and try it out for yourself. It’s fairly simple in UI / UX terms, but hopefully it’s got enough features to be a fun addition you your phone or tablet. I’ve tried to support the widest range of devices possible so anything with Froyo onwards and the right hardware should be just fine…

Get it on Google Play

Implementing Entity Services using NoSQL – Part 4: Java EE


Now that I have prepared a skeleton contract-first web-service and created a data access layer using Ektorp and CouchDB, it’s time to wire them together into a fully working entity service. To do this I’m going to use Java EE and Glassfish 3.1.

It’s worth noting at this point that it’s not strictly necessary that I use Java EE at all for his kind of R&D work. I don’t need the security or the transaction features that are provided by a JEE server like Glassfish and I could probably use something a little lighter like Tomcat or Jetty. However, I do like the convenience and the features of JEE, and many applications that begin life on an standard Java application server like Tomcat do end up either grafting JEE features into Tomcat (like JAX-WS) or migrating to a full JEE server like Glassfish.

(more…)

Implementing Entity Services using NoSQL – Part 2: Contract-first


It’s time to begin the coding of my SOA entity service with NoSQL project, and as promised I’m starting with the web service’s contract.

This technique of starting with a web service contract definition is at the heart of the ‘contract-first’ approach to service-oriented architecture implementation and has numerous technical benefits including…

(more…)

There’s no such thing as a pre-packaged SOA.


It’s unfortunate, but Vendor’s, SI’s and VAR’s regularly mis-sell SOA.

Let me give you one simple example…

About 12 months ago during an RFP demonstration, a big name software Vendor suggested that their “3,500 ready made services would deliver SOA out of the box”. They even claimed that somehow 3,500 services was a mathematically optimum number an implying that everyone would need this number of services eventually-  so why try and do it yourself?

Clearly this promise of a ready made service inventory could be very tempting to the uninitiated – but it’s just plain wrong. It’s like someone dumping a keyboard with 3,500 keys on your desk and then telling you that it can make you type faster. It’s simply not true.

In reality this particular vendor’s API had more likely been the result of a quick and dirty hack to expose an old functional API as a bunch web services. They could do this by simply turning each ancient API function into one operation on one web service. But the resulting service inventory would be a vast and unfathomable hodgepodge where every service API was designed at the same level of granularity and with the wrong level of coherence (both OO terms but they’re appropriate here). Ultimately this leads to an implementation nightmare where a considerable amount of complex service composition would be required in order to perform even the most basic of tasks.

Furthermore, regarding the 3,500 web services is optimal claim, the only math that I’m aware of that would make a difference to service interface design is Partition Theory and Partition Theory quite clearly states that a simple 1:1 mapping of services to operations (like those in this particular API) is very rarely the optimal arrangement and would more likely lead to highly inefficient solutions.

When challenged about this, the vendor’s ‘ingenious’ solution (I’m being generous here, I actually mean ‘demented’) was for the client to licence some more of their SOA tools to help with the burden created by this massive inventory of services. They’d need a registry to help with the discovery problem and a process management tool to help develop the large number of service compositions they’d need to build to do anything useful with their 3,500 services. This would of course require additional capital outlay, infrastructure and training and would inevitably deepen the vendor lock-in even further.

Fortunately, my private sector client at the time did evaluate the situation correctly and didn’t take the proposal any further. However, in less experienced teams this kind of mis-selling could go completely unchecked and could end up costing organisations a small fortune in scope creep and additional integration and implementation effort.

So what’s the solution?

I’d like everyone to understand this simple fact and use it to their advantage:

SOA can’t be packaged and sold!

The only way to get an architecture that is naturally service-oriented and fits the way that your business operates is to design it that way. There is no such thing as a pre-packaged SOA that can be bought off the shelf. Service-oriented solutions need to be designed by you, for you.

Vendors, SI’s and VAR’s currently find it all too easy to exploit customers who don’t have an expert SOA practitioner on their team. So my advice is for you to do yourself a favour and go and get one as soon as possible. It could be the best decision you’ll ever make and given the prices quoted by SOA vendors I’m confident you’ll see a phenomenal return on that investment within a very short space of time.

How to build a DIY Service Repository


[UPDATE] The code sample to support this article is now available on GitHub.
The full version of this article is on InfoQ: “DIY SOA: How to build your own Simple Service Repository“.

Every Jedi faces the moment in their life when their Lightsaber simply fails to perform as expected and he or she has bite the bullet and build a better one.

Not being a Jedi I clearly have no use for a Lightsaber, but I did have a recurring irritation in the form of the service registries and repositories. These tools often claim to support good SOA principles and practices (like discoverability and contract-first service development) but in my view they often fail to live up to the hype.

Service Registries/Repositories fall into two basic camps. There are the commercial large vendor offerings from the usual suspects and the smaller open-source attempts.

Being a lightweight agile kind of guy (not literally, sadly) I’m constrained a strong value-vs-cost ethic. To my mind the commercial offerings are basically too bulky, too demanding and too expensive to be of any interest. That leaves the open-source offerings, which are rather thin on the ground, can have limited functionality and are not terribly well thought through in terms of the functionality that I think multi-disciplined team of users would need.

So to cut a long story short I decided to build my own ‘DIY Simple Service Repository’ using low-cost open-source tools and technologies.

What I wanted from my Simple Service Repository.

A good service repository should support the principles of good service-orientation. Specifically, a service repository should allow for a high degree of service contract standardisation, support contract versioning, promote contract-first service development and enable easy service discoverability (preferably at both design time and at compile time). Let me explain what I mean by these requirements.

Contract standardisation is the practice of supporting abstraction, loose coupling, federation and reuse in service contracts by centralising artefacts like XML Schemas, abstract WSDL‘s and WS-Policy documents. Reuse of XML Schema’s is particularly important as it is a key enabler for ‘intrinsic interoperability’ whereby services communicate using the same data model. By having all my contracts, data models and policies in one place I can reuse them easily and as often as I like.

Contract versioning can be quite a difficult process but I want a simple solution where all the decisions regarding the versioning of contracts, policies and data models are mine. I’m not going to ask much from my simple service repository, I simply want it to hold ‘releases’ in separate version controlled directories that are independent of each other. I’d like releases to be addressable via a URL and be viewable in the users browser.

Contract-first development (of SOAP based web services) is important because it ensures that the service contracts remain loosely coupled and independent from the underlying implementation technology. Contract-first often entails a service designer designing the required contracts and developers ‘importing’ them into their build as the basis for a service’s implementation code. This can often be a source of some discomfort for developers who may be used to controlling their own destiny, so making it an easy process can help to overcome any potential objections that may arise.

Finally, easy service discoverability benefits service-oriented architectures because by making services highly visible we can reuse them more readily and also prevent ‘accidental’ duplication from occurring. Duplicate, competing, unused or redundant services can confuse and dilute the effectiveness and power of your SOA, hampering its ability to serve its community. These issues can be avoided (and reuse promoted) if service contracts can be easily discovered by anyone at any time.

By creating a place to centrally store service contracts (and other design time information like WS-I BP compliance documents or human readable interface documentation) we can achieve all of these goals and add some real value to our SOA analysis, design and development practices.

Enter: The SOAGrowers ‘Simple Service Repository’.

So here is my solution. Just follow my 3 simple steps and you’ll have a simple service repository in no time…

1. Create a Java web application (the Simple Service Repository application) using Maven.

The source for this project is hosted in my SVN server. The application includes browsable folders for the WSDL, XSD and WS-Policy documents and SVN keeps everything nicely version controlled. HTML and CSS provides the basic glue that binds everything together, but you could investigate using a Wiki maybe if you don’t like HTML. I’ve included some screenshots below if you want to see what it looks like in real life.

2. Build & Deploy the Simple Service Repository application to an application server.

Jenkins is an open-source continuous integration server and sits as another application on my Glassfish server. Jenkins is configured to build and deploy my application whenever it notices a change in the SVN repository.

Glassfish 3.1 is my personal application server of choice for Java web applications other servers could work just as well. Once hosted, the Simple Service Repository’s HTML pages are instantly available via a browser and I’ve also used a specific Glassfish deployment descriptor which makes my content folders browsable by default.  These features help satisfy my basic ‘discoverability at design-time’ requirement.

When Jenkins builds my service it calls Maven’s ‘install’ which places the Simple Service Repository web application [WAR] and all the service contracts it contains into my Maven repository as a versioned Maven artifact. This is very handy for the next bit…

3. Build a SOAP based Web Service from a contract hosted in the Simple Service Repository (and test it).

Maven again comes to the rescue again, using a Maven ‘copy’ plugin to extract the service contract from the WAR in the Maven artifact repository during the ‘init’ phase before using the JAX-WS plugin to create a service implementation framework in Java from the extracted WSDL contract. If I didn’t like the copy approach I could probably ask wsimport to just use the URL for the contract (pointing to the Simple Service Repository’s copy of the WSDL on the application server).

The rest is plain sailing – normal boilerplate JAX-WS service implementation code. In my build I use the Cargo plugin for Maven to deploy the service implementation to Glassfish and SoapUI’s Maven plugin to run a service integration test suite during every build.

On the build server, this service is also built by Jenkins, but this time its triggered by the Simple Service Repository application being successfully re-built. That way, if the service contract for my service changes, my application gets immediately re-built and re-tested so that I’ll know if I’ve introduced a defect into the system.

In some very simple cases, the service project is so light that it only contains a few class files. Because JAX-WS can do annotation based deployment there can be very little in the way of metadata like deployment descriptors etc.

An overall view of the Simple Service Repository solution in action.

A job well done?

So there you have it, version 0.1 of the the Simple Service Repository is complete.

It’s storing my service contracts centrally, it’s making them discoverable, it’s supporting contract-first development and it’s alerting me if I introduce changes to my contracts that destabilise my service implementations. It’s even supporting simple release based versioning of contracts and data models.

To my mind it fits the brief perfectly. It’s highly available and accessible, repeatable, manageable and provides a valuable platform that supports closer collaboration between service designers and service developers.

More importantly it was very quick and easy to create. It requires zero code (if you don’t count HTML as code), it cost me about a day in development time and it draws nicely on existing low-cost open-source tools and techniques. It also requires very little infrastructure and will run nicely on a normal laptop. I could probably even put it into the cloud without too much additional development effort.

In summary, I’m still no Jedi (unfortunately) but I’m happier with my ‘DIY’ Simple Service Repository than I have been with anyone else’s.

Sample Code:

The sample code that supports this article is available on GitHub.

About the author.

Ben Wilcock is a freelance SOA Certified Architect with a reputation for delivering exceptional Service Oriented Architectures. You can read his blog at https://benwilcock.wordpress.com/ or contact him via his website at http://www.soagrowers.com/“.

The Importance of Truth…


Call them what you will, “Truths”, “Product Owners”, “Business Representatives” etc. If you’re doing agile, they need to be very opinionated and focussed on what they want from the solution. Otherwise progress will be difficult, and the end result unpredictable.

The same is true before the project gets underway. When IT asks for the money on behalf of someone else, you can bet that the commercial reasoning will not be as strong as it should be, and the product owner uncertain about what it is they really need.

In my opinion the most successful projects (and solutions) always have confident, focussed Product Owners. In fact, it could be argued that its best not to start an agile project without one.

Personally I’ve ever actually worked on a waterfall project, but perhaps this is one area where waterfall had a slight advantage? The up front documentation probably gave you a chance to build consensus and ‘forge’ a Product Owner if an obvious candidate didn’t materialise naturally.

What do you think?