Rich Internet Applications (RIA)

This article originally appeared in the May 2010 edition of GroovyMag, the Groovy and Grails magazine. Parts 3 and 4 are currently available for download from the magazine’s site, and more will come each month. Enjoy!

The Groovy Programming Language advertises itself as an “agile and dynamic Language for the JVM”, but what does this mean exactly? This series of articles explains Lean Software Development, and shows how your choice of programming language can make your entire process remain nimble and adaptive. Each month will cover one of the seven Lean Software Development principles and explain how Groovy and the associated ecosystem help eliminate waste, defer commitment, and build quality into your product.

About this Series

Groovy is an agile programming language. In order to explain what this means, these articles are structured around the seven principles of Lean Software Development. Last month included a short introduction to Lean, and explained how an expressive language can eliminate waste in unit testing. This month we’ll see how the easyb Behavior Driven Development framework and Groovy Builders can build quality into your life-cycle. In later months we’ll explore how different testing tools like the Spock Framework help create knowledge, how a dynamic language lets you minimize coupling and defer commitment, and how metaprogamming allows you to deliver fast. In future installments you’ll see how Groovy’s Grapes module system, alongside modules like Groovy Web Services, streamline interactions between development and other groups like operations and QA… an important aspect of respecting people. Finally, we’ll look at optimizing the whole by applying Groovy to domains that cross department boundaries: how Gradle improves the build process and easyb serves as a collaboration mechanism between different organization roles. The series will end with a discussion on the best practices of mixing Java and Groovy.

Some of the code examples are basic while others are advanced. The articles explore why the features of Groovy are important rather than the mechanics of any one Groovy feature. Hopefully you’ll leave with some new ideas about how to use Groovy, how to convince your team that Groovy is worthwhile, or most importantly how to increase your productivity.

Lean Revisited

Part 1 of this series contained a more indepth explanation of Lean, and I won’t repeat it here. But as a quick refresher here are the 7 lean principles along with a summary for those principles covered previously:

1. Eliminate Waste – Reduce work in progress and half done work
2. Build Quality In
3. Create Knowledge
4. Defer commitment
5. Deliver Fast
6. Respect People
7. Optimize the Whole

Principle 2 – Build Quality In

If you want to build a high quality product, you could inspect your product after it is built to ensure that it conforms to standards. But it would be better to change how the product is made so as not to create defects in the first place. Picking the best of breed testing practices and using them before the system is completely built is of utmost importance to quality software. At one point in time JUnit and Java were the state of the art in software testing, and eventually Test Driven Development gained mind-share in the industry, pushing testing into the same phase as development. Today, some of the best tools and practices are coming from the Behavior Driven Development community. Groovy is lucky to have an excellent choice for BDD in the Jolt Award winning easyb framework.

Instead of writing tests, easyb focuses on writing “stories”. A story is a piece of functionality that is visible and meaningful to the user. The intent is different than unit testing, although it does occur frequently at the same level. Stories are expressed in a given/when/then format. For instance, the story for a web service might be: given a user web service, when a user is looked up in the web service, then the user’s record should be found. The example in Listing 1 might make this clearer.

using "xmlunit"
scenario "web service should return XML based users", {
  given "a user web service ", {
    service = new UserWebService()
  }
  when "a user is looked up in the web service", {
    webServiceResult = service.get(123456)
  }
  then "the user's record should be found ", {
    webServiceResult.shouldBeIdenticalTo """
        <user id= "123456">
        <firstname>John</firstname>
        <lastname>Doe</lastname>
        </user>"""
  }
}

Listing 1: A Simple easyb story using XMLUnit

To understand the low ceremony nature of easyb, understand that Listing 1 is the entire file. There is no setup, test class subclass, or magical annotation incantation required. The essentials of your test are what it is testing, not the mechanics of a test framework. Easyb works with you in achieving a test with only the essentials being communicated.

You may have also noticed a lack of variable declarations. Where are these variables declared and what are their scope? Again, declarations are rarely an essential part of a unit test, so easyb handles this for you. Variables are scoped within the scenario they are used and instantiated when referenced. Easy, and with a lot less fluff than Java. Hopefully you are wondering how all of this works (if not then skip to the next paragraph)! Remember, parenthesis are optional in Groovy method calls, and {} is used to create a closure. In this easyb story, scenario, given, when, and then are all just normal methods that take a String and a Closure as parameters. While it may look terse enough to be qualified as a domain specific language, this is for the most part just plain old Groovy. The implicit variable declarations are a little harder to explain, but suffice it to say that a little metaprogramming is happening under the covers.

At first glance, easyb might appear to be a lot different from the traditional JUnit approach. Some of it is quite different, which gives easyb its power. But for the most part, it is plain old Groovy and is a good JVM citizen. There is plenty of build system support for easyb (an Ant task and plugins to other systems), IDE support for at least IntelliJ IDEA and Eclipse, and other JVM tools like code coverage applications should still work with it. If you are serious about building quality into your product, then take a hard look at using BDD and easyb to drive down defects before they appear in the QA phase.

Behavior Driven Development

BDD bills itself as “Unit Testing Done Right “. So what was wrong with unit testing? Unit testing is a good start, but often addresses how objects behave at the microscopic level rather than focusing on what matters to stakeholders. BDD changes this by focusing testing back on the project and the value of the system. Developers are encouraged to focus on why tests should be created rather than adhering slavishly to a one test per object approach. It might sound more like functional testing than unit testing.

The way to focus tests back on business value is by developing and using a ubiquitous language. When your customer says, “The user should be able to change their password,” then that should be your test name. Calling your test fixture UserManagerTest, your test method testChangePassword, and your assertion assertEquals creates an artificial language barrier between you as a developer and the business. It is better to call the test User Features, the test method user must change password, and the assertion should be. A common and ubiquitous language breaks down barriers between you and the business and keeps you focused on why you’re writing the system in the first place.

Groovy Builders

Another Groovy language feature useful in achieving low ceremony testing is multi-line Strings. Strings may be triple quoted, like in the Listing 1, and then all special characters and whitespace may be embedded in the String without escaping or concatenation. This makes working with XML a breeze: no need to litter your test with long blocks of string concatenation, nor do you need to hide the XML snippets away in an external file where they aren’t visible when the test fails.

Building data, and lots of it, is a common occurrence in unit tests. Multi-line Strings are nice, but are definitely not the only way to build String based data. One of the most helpful classes in the Groovy library is the MarkupBuilder, as seen in Listing 2.

def writer = new StringWriter()
new groovy.xml.MarkupBuilder(writer).
   user(id: 123456) {
      firstname('John')
      lastname('Doe')
   }

Listing 2: Creating an XML tree with MarkupBuilder

<user id= "123456 ">
   <firstname>John</firstname>
   <lastname>Doe</lastname>
</user>

Listing 3: XML output from Listing 2

The MarkupBuilder is a dynamic object that treats method calls as requests to build markup (whether it be XML or HTML). Calling a method, any method, is going to create an XML Node with the tag named the same as the method. Passing a key/value pair is going to add an attribute to that node, and passing a value is going to write that value as the node value. In Listing 2, all of this is written into the StringWriter object. The real power of MarkupBuilder comes when mixing dynamic method calls with real, statically declared method calls like List.each().

In Listing 4, the users() and user() method calls are calls on the MarkupBuilder, and will have start and end tags generated correctly, while the names.each() method is an invocation on the variable called names that is in scope. Building ad-hoc test input and test control data is greatly simplified by understanding and working with builders.

def names = ['Alice', 'Bob', 'Carol', 'Ted']
def writer = new StringWriter()
new groovy.xml.MarkupBuilder(writer).
   users {
      names.each { name ->
         user(name)
      }
   }

Listing 4: Mixing MarkupBuilder and Lists

Listing 5: Output from Listing 4

Don’t just rely on this builder though. Write your own builder for working with any sort of structured data. Any tree like data structure is a good candidate, as well as APIs that require heavy usage of setParent() or setChild() method calls. All of this can be hidden behind a builder. There is even an abstract class called BuilderSupport that takes care of all the heavy lifting.

Before writing your own builder with BuilderSupport, it pays to understand how the object works to capture arbitrary dynamic method calls. Listing 6 shows all the possible ways to interact with a Groovy builder. There are four options: you may invoke dynamic method calls with no parameters, a
single value parameter, a Map parameter, or a Map and a value parameter.

new groovy.xml.MarkupBuilder().root() {
   valueNode('a value')
   attributeNode(a: '1', b: '2')
   mixedNode(a: '1', b: '2', 'a value') {
      nestedNode()
   }
}

Listing 6: Possible Uses of Markup Builder

All of these methods take an optional closure parameter that lets you nest nodes arbitrarily deep. To generalize the builder pattern, there are 4 possible ways to invoke a dynamic method. With this in mind, the abstract BuilderSupport class is a logic implementation for a base builder class. If you want to create a new builder, then you need to implement four abstract methods, one for each type of dynamic method invocation. The BuilderSupport abstract methods can be seen in Listing 7.

class BuilderSupport {
   ...
   abstract Object createNode(Object name)
   abstract Object createNode(Object name, Map attrs)
   abstract Object createNode(Object name,
   Map attrs, Object value) abstract Object createNode(Object name, Object value)
   ...
}

Listing 7: BuilderSupport Abstract Class

What BuilderSupport does for you is handle all of the dynamic dispatch and nesting with closure parameters. Writing a new builder, and enjoying the accompanying Groovy “magic” really is as easy as implementing these four methods. You’ll get the most value from a builder by taking a few minutes early in the project to write one as a wrapper around your tree-like API.

Next Steps

One particularly rigorous Lean practice is a zero tolerance or stop the line approach for defects. The idea is that no defects should exist in the system, and when a defect is present then all attention and effort must be focused on resolving the issue before normal work resumes. In the face of error conditions and ambiguities, the assembly line stops until the issue is resolved. The effect is that your daily process becomes fine tuned around producing a high quality product early in production as opposed to optimizing a defect cycle days or weeks later. Stop the defects before they happen. My team recently applied this approach for a single two-week iteration with interesting results. Based on our retrospectives, we decided to not continue with a strict enforcement of this policy, but we all agreed we learned a lot and the lessons learned were carried forward to our current process. A worthwhile experiment; I suggest you try it.

Next Month: Create Knowledge

Software Engineering is a knowledge creating process. It is important to find the correct balance between tacit, organizational knowledge and explicit, recorded knowledge. Next month’s article explores what this means, looks at ways to use Groovy to capture and codify knowledge, and discusses the differences between terse and expressive. Along the way we will see some cool new features of Groovy and the amazing Spock testing framework.

Learn More

Everyone learns differently, and for me the best way to learn about a new framework is to experiment with it. Easyb can be downloaded from http://www.easyb.org/ and BuilderSupport is a standard Groovy class. Otherwise, the web contains many tutorials on both subjects, and “Programming Groovy” by Venkat Subramaniam contains an in-depth BuilderSupport chapter. The MEAP pre-release for “Groovy in Action 2nd Edition ” does not yet (at the time of this writing) contain Builder information, but it should be coming out shortly.

For books on agility, I still contend these three cannot be beat:

• Implementing Lean Software Development – Poppendieck
• The Pragmatic Programmer – Hunt and Thomas
• Extreme Programming Explained, 2nd Edition – Beck and Anders

This entry was posted on Monday, July 5th, 2010 at 12:55 pm by Hamlet and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.