Testing Alfresco webscripts

Waaah, too boring to test is too boring to write.

I just wanted to start with this quote from Ray Ryan in Architecting GWT applications for production at Google session at Google I/O 2010.

This really explains how I feel about extending Alfresco. Actually it is worse than that, writing tests for Alfresco extensions is painful rather than boring.

While developing extensions for Alfresco, I often find writing even the simple unit tests unnecessarily difficult. I think the reason is that it is not designed testability in mind. You don’t have the necessary abstraction in the source code to ease unit testing; not enough interfaces, no separation of concerns.

As a result it is not usually possible for the developer to isolate the functionality that will be tested. I usually find myself trying to hack some stuff and bend the earth 🙂 Unfortunately you can not bend everything, right?

Unit tests is not the big deal, you might somehow find your way in the dark. What about integration testing? It is even more difficult, everything is tightly coupled with the repository and you mostly need an up-and-running Alfresco instance.

And then comes the webcripts, functional testing. That is easy right, fire up an Alfresco instance with your custom webscripts deployed and apply the usual routine. Make an HTTP (GET, POST whatever it is) call and check the response to see if everything is OK. What if you need test data? How are we going to create the test data that that particular webscript needs?

If you are thinking about using Alfresco WebService Client, you must be crazy! I will never write those long boring lines of webservice calls to create a couple of folders and documents. Why? Because it is BORING. Remember? Too boring to test is too boring to write.

As you may know from my previous blog posts that we are currently developing a CMS back-end with Alfresco+GWT for our consumer facing website. The first thing we did was to write a test data preparation framework for functional tests –also for integration tests since you mostly need a running Alfresco instance–. We also used the Alfresco WebService Client but in a slightly different way. We created a DSL using Groovy on top of Alfresco WebService Client.

Now whenever I need test data to be created for a particular test, all I have to do is to override the following method from my base test class.

@Override
public Closure getData() {
  return {
    node(UUID.randomUUID().toString()) {
      nodeType = "{http://www.xxx.eu/model/content/1.0}imageFamily"
      aspects = ["{http://www.xxx.eu/model/content/1.0}item"]
      PROP_XXX_BATCH_NAME = 'example'
      rule(["inbound"], "image family", "image family/sibling related rules") {
        action("composite-action") {
          condition("no-condition")
          action("create-image-family") {
          }
        }
      }

      node(UUID.randomUUID().toString()) {
        nodeType = "{http://www.xxx.eu/model/content/1.0}imageSibling"
        aspects = ["{http://www.xxx.eu/model/content/1.0}item"]
        PROP_XXX_IS_ORIGINAL = true
        PROP_XXX_IS_TRANSPARENT = false
        PROP_XXX_X_RESOLUTION = 36
        PROP_XXX_Y_RESOLUTION = 72
        PROP_XXX_WIDTH = 100
        PROP_XXX_HEIGHT = 100
        content = file("images/50647.jpg", "image/jpg")
      }
    }

    folder("Folder_1") {
    }
  }
}

What is does is;

• creates a node of type imageFamily, sets some attributes on the node and applies a rule on that node
• creates another node of type imageSibling under the first one and sets some attributes on that
• creates a folder with name Folder_1 at the same level as the first node

However I think this is not something I should do. Alfresco guys should provide these kind of frameworks and it is not that hard to do it. If you are hearing what I am saying, just send me an email I would be more than happy to help you about that.

A good framework should come with it’s own testing framework. We love Spring, you know why…