Blog from March, 2009

Gmock 0.7.0 released

We are extremely pleased to announce the release of Gmock 0.7.0. Gmock is a mocking framework for the Groovy language. Gmock is all about simple syntax and readability of your tests so you can spend less time learning the framework and more writing code.

This release bring two long awaited features: strict ordering and partial mocking.

Strict ordering is accomplished through the ordered closure. Here is an example with an hypothetic cached cat database:

The partial mocking is performed simply by using the mock method on your concrete object. Here is how it works with a grails controller:

Gmock 0.7.0 is the last release compatible with Groovy 1.5.x. Support for Groovy 1.6.0 is coming soon in our next release.

Please visit http://gmock.org or http://code.google.com/p/gmock/ for more information.

We are looking for your feedback and how you feel we could improve Gmock in the route to the 1.0.0.

The Gmock devs

Griffon 0.1 released

The Griffon Development Team is proud to announce the release of Griffon 0.1.

Griffon is a Grails-like framework for developing Desktop and Rich Internet Applications for the Java platform. The 0.1.0 is the second major release of the project and contains many new features. The main new features are:

  • Plug-in support, based on the Grails 1.1 plug-in architecture
  • MVC Group API enhancements
  • WebStart enhancements
  • A new build and runtime events API

More detailed release notes are available at http://docs.codehaus.org/display/GRIFFON/Griffon+0.1 and bits can be downloaded at http://dist.codehaus.org/griffon/griffon/0.1.x/

What is Griffon?
Griffon is a development framework much like Grails. Instead of developing web applications, Griffon focuses on desktop and rich internet applications. Developers write their applications in a structure much like Grails and written in the Groovy and Java Programming Languages targeting the Java platform. Griffon aims to reduce development time by leveraging dynamic language features in addition to automating routine development tasks via the "Convention over Configuration" idiom.

Meet Spock!

Spock is a new testing and specification framework for Java and Groovy developers. When spreading the word about Spock, I often get the question: "Why on earth would I need yet another testing framework? Aren't there enough xUnit/xSpec clones out there already?" In this post, I'll try to show you how Spock is different, and why it is worth a closer look.

Assertions

Assertions are the most fundamental way to express how a piece of software should behave. It's almost a tradition that every new testing framework comes with its own assertion API, adding a few wrinkles here and there, and naming things a little differently. For example, to say that two things are equal, you would typically write something like:

  • assertEquals(x, y)
  • x.shouldEqual(y)
  • x.mustBe(y)

Every now and then, a stranger comes along and asks if he can't just use plain boolean expressions instead of an assertion API. But we all know that boolean expressions can't tell us why they failed. Or can they? Meet Spock!

In Spock, assertions come after the expect: label, and are just what the stranger asked for - plain boolean expressions! Here is what we get when we run this test:

Of course this doesn't just work for simple comparisons, but for arbitrary assertions. Here is another, slightly more interesting output:

Again, Spock's runtime has collected all relevant information, and presents it in an intuitive way. Nice, isn't it?

Data-driven tests

Although data-driven testing is a natural extension of state-based testing, it doesn't seem to be used very often. I suppose this is because test frameworks make writing data-driven tests rather hard. All of them? Meet Spock!

The expect block provides just the test logic, using the free (i.e. undefined) variables a, b and c as placeholders for data. It's then up to the where block to bind concrete values to these variables. When this test is run, it is repeated three times: first with a = 7, b = 3, and c = 7; then with a = 4, b = 5, and c = 5; and finally with a = b = c = 9.

Of course, the test data doesn't have to be baked into the test. For example, let's try to load it from a database instead:

Here the values for a, b, and c are taken from the equally named columns of the maxdata table, until no more rows are left. Using a syntax similar to Groovy's multi-assignment, the where block can be simplified even further:

Together with the creation of the Sql instance above, we are now down to two lines of code to load our test data from a database. How easy is that?

Summary

Assertions and data-driven tests are just two areas where Spock achieves more with less. At http://spockframework.org, you will also meet Spock's incredibly lean mocking framework, its interception-based extension mechanism, and other fascinating life forms. If you have any questions or suggestions, please write us at http://groups.google.com/group/spockframework, or file an issue at http://issues.spockframework.org. I'm looking forward to your feedback!

Peter Niederwieser
Founder, Spock Framework
http://spockframework.org

Hello! Some important changes are coming in the newest version of HTTP Builder, and I wanted to get feedback from the community while this is still in development.

I've released an experimental snapshot that includes a prototype REST client API, as well as some breaking changes from 0.4.x. HTTPBuilder is a streamlined HTTP client API built on Apache's robust HttpClient.

First, the good news:

v0.5 will include RESTClient, which aims to make REST operations as pain-free as possible. Whereas HTTPBuilder is optimized to parse streaming response data, RESTClient assumes the response can easily be read into memory. This is how HTTPBuilder's default response handler works currently, but RESTClient goes one step further and provides simplified access to response headers and the parsed data without any inline closure at all.

An Example:

Notice how JSON and XML are used interchangeably, and the response is automatically parsed based on the response content-type header. This API is still in development, so suggestions for improvement are more than welcome!

Now the bad news; breaking changes from 0.4.x...

The main breaking change is that all "url" parameters and named arguments are being changed to "uri." This is mainly because Apache HttpClient uses URIs, not URLs for its operations. So it was inconsistent and misleading to use the term "URL" when in fact, it is a URI. There are a few other minor changes, but they are expected to be low impact. You can see a list of changes for 0.5.0 here.

The HTTPBuilder homepage has not yet been updated, but a snapshot release is available for eager users to test out.

Comments and feedback are welcome. Site documentation should be updated within a week. Enjoy!

GParallelizer 0.6 released

The Groovy implementation of the actors concept popularized mostly by Erlang or Scala has reached an important milestone. Version 0.6 of GParallelizer (http://code.google.com/p/gparallelizer/) has been made available for you to download, experiment and use.

Here's a short example of using actors to simulate a number guessing game:

import org.gparallelizer.actors.pooledActors.AbstractPooledActor

class GameMaster extends AbstractPooledActor {

      int secretNum

      void afterStart()
      {
              secretNum = new Random().nextInt(10)
      }

      void act()
      {
              loop
              {
                      react { int num ->
                              if      ( num > secretNum )
                                      reply 'too large'
                              else if ( num < secretNum )
                                      reply 'too small'
                              else
                              {
                                      reply 'you win'
                                      stop()
                              }
                      }
              }
      }
}


class Player extends AbstractPooledActor {
      String              name
      AbstractPooledActor server
      int                 myNum

      void act()
      {
              loop
              {
                      myNum = new Random().nextInt(10)

                      server.send myNum

                      react {
                              switch( it )
                              {
                                      case 'too large': println "$name: $myNum was too large"; break

                                      case 'too small': println "$name: $myNum was too small"; break

                                      case 'you win':   println "$name: I won $myNum"; stop(); break
                              }
                      }
              }
      }
}

def master = new GameMaster().start()
new Player( name: 'Player', server: master ).start()

The example given by Jordi Campos i Miralles, Departament de Matemàtica Aplicada i Anàlisi, MAiA Facultat de Matemàtiques, Universitat de Barcelona

The actors may internally share a thread pool, the size of which can be much smaller than the number of actors working on your algorithm and so saving your system valuable resources.
More examples are available at http://code.google.com/p/gparallelizer/.
The recent introductory blog post can be found at http://www.jroller.com/vaclav/entry/event_based_actors_in_groovy.

Now I'd like GParallelizer to face the reality and evolve further based on real needs. Don't hesitate to comment or discuss.

Václav Pech

GroovyMag March 2009

The March 2009 GroovyMag is available, with articles on

  • AJAX Forms in Grails
  • New GORM features in Grails 1.1
  • Groovy Under the Hood
  • using the Grails Help Balloons plugin
  • and more!

    Get yours today from http://groovymag.com/latest |

The Tellurium Automated Testing Framework (Tellurium) is a UI module-based web automated testing framework implemented in Groovy. The UI module is a collection of UI elements you group together. Usually, the UI module represents a composite UI object in the format of nested basic UI elements. For example, the Google search UI module can be expressed as follows,

ui.Container(uid: "GoogleSearchModule", clocator: "td", group: "true"){
   InputBox(uid: "Input", clocator: "Google Search")
   SubmitButton(uid: "Search", clocator: "btnG", value: "Google Search")
   SubmitButton(uid: "ImFeelingLucky", clocator: "I'm Feeling Lucky")
}

The UI module makes it possible to build UI elements' locators at run time. The framework doesObject to Locator Mapping(OLM) automatically at run time so that you can define UI objects simply by their attributes, i.e.,Composite Locatorsdenoted by the "clocator". Furthermore, Tellurium uses theGroup Locating Concept(GLC) to exploit information inside a collection of UI components to help finding their locators and the GLC is denoted by the "group" attribute in the above UI module.

The Tellurium framework defines a newDomain Specific Language(DSL) for web testing. Still take the above Google search module as an example, you can use the following DSLs to do a Google search,

type "GoogleSearchModule.Input", "Tellurium test"
click "GoogleSearchModule.Search"
waitForPageToLoad 30000

Tellurium UI Model Plugin (TrUMP) is the Firefox plugin to automatically create UI modules for users.
We are glad to announce that TrUMP 0.1.0 Release is out and please download it from Tellurium download page at

http://code.google.com/p/aost/downloads/list

The release includes two xpi files, one for Firefox 3 and one for firefox 2. Basically there are the same, the firefox 3 one utilized some advanced features provided by Firefox 3 to display UI.

The main features of TrUMP 0.1.0 include

  1. Record user's clicks to automatically generate UI module
  2. Validate the UI module
  3. Customize the UI module
  4. Export the generated UI module to a groovy file
  5. Logging support
  6. Preference support

The known issues or limitations include

  1. Cannot record popup/dialog window
  2. Does not support UI template yet. This feature will be provided in later versions.

The detailed steps on how to install and use TrUMP could be found at

http://code.google.com/p/aost/wiki/TrUMP

On the download page, we provide video demos on how to use TrUMP to create UI modules and how to write Tellurium tests using the generated UI module. We also provide a presentation about Tellurium there.

If you are interested in how TrUMP is implemented, you can find the following tutorial

http://code.google.com/p/aost/wiki/HowTrUMPWorks

It would be really helpful for us to improve TrUMP if you could try it and post your problems and suggestions to Tellurium user group at

http://groups.google.com/group/tellurium-users

Thanks in advance,

Tellurium team