Setting an entity property as a list with Gaelyk and Google Appengine

As the Gaelyk site says, “Gaelyk is a lightweight Groovy toolkit for Google App Engine Java.”

Gaelyk makes it easier and Groovier to play with datastore entities, allowing the following syntax for creating and saving Entity:

import com.google.appengine.api.datastore.Entity

//create the entity
Entity student = new Entity("person")

//set and populate properties
student["name"] = "John Doe"
student["grade"] = "8"

student.save()

What you can’t do with this easy syntax is save a property as a list; the following line fails:

//failed attempt to make the property a list
student["colors"] = ["blue", "green"]

Instead, you have reach further down to the Entity class API:

import com.google.appengine.api.datastore.Entity

//create the entity
Entity student = new Entity("person")

//set and populate properties
student["name"] = "John Doe"
student["grade"] = "8"

//make the property a list first
student.setProperty("colors", [])
student["colors"] = ["blue", "green"]

student.save()

Canoo Webtest, Groovy, and Maintaining Session with Tests

The open source Canoo Webtest is a powerful tool for automating functional and regression tests for your web application. You can script your test steps in XML or in Groovy (or a mix of both), and you can build a comprehensive library of test steps that you combine and reorder into your tests.

The documentation for Webtest is a little sparse when it comes to scripting it with Groovy, and I burned some cycles getting the solution, so I’m documenting it here.

With Webtest tests written in XML, the executable test is the “webtest” Ant task. Repeatable sequences of steps are saved in XML files, and included into that test. For example, here’s a login sequence saved as includeLoginSequence.xml:

<group description="Successfully Log in">
    <invoke description="Go to home page" url="${path}"/>
    <selectForm name="login"/>
    <setInputField description="set user name" name="username" value="myname"/>
    <setInputField description="set user password" name="password" value="mypassword"/>
    <clickButton name="login" description="Click the login button"/>
</group>

And that sequence of steps gets included into the Webtest test:

<webtest name="Log in and go to page 2">
    &includeLoginSequence;
    <invoke description="Go to page 2" url="/page2"/>
</webtest>

Now, this isn’t all you need to run the test, but the key points here are the mechanism for saving and including “chunks” of repeatable step sequences, and the fact that all steps contained within the “webtest” ant task are executed within the same session. That last point is crucial: in order to maintain the session across all test steps, they must be in the same webtest container.

For Webtest tests written in Groovy, the paradigm is a little different. The tests are in a class that extends grails.util.WebTest and ends with the word “Test”, with the steps in a method that begins with the word “test”. For example:

class LoginSuccessfulTest extends grails.util.WebTest
{
    protected def loginSuccessful(path="/home") {
        webtest(name:"Log in and go to page 2") {
            group(description: "Successfully Log in") {
                invoke(description:"Go to home page", url:"${path}")
	        selectForm(name:"login")
                setInputField(description:"set user name", name:"username", value:"myname")
                setInputField(description:"set user password", name:"password", value:"mypassword")
 	        clickButton(name:"login", description:"Click the login button")
                invoke(description:"Go to page 2", url:"/page2")
            }
        }
    }
}

In order to get a sequence of test steps that is repeatable and can maintain session, you need an inherited class that contains a method with the desired sequence. So start with a class that has the sequence but will not be executed as a test itself:

public class LoginBase extends grails.util.WebTest
{
    protected def loginSuccessful(path="/home") {
        group(description: "Successfully Log in") {
	    invoke(description:"Go to home page", url:"${path}")
	    selectForm(name:"login")
            setInputField(description:"set user name", name:"username", value:"myname")
            setInputField(description:"set user password", name:"password", value:"mypassword")
 	    clickButton(name:"login", description:"Click the login button")
        }
    }
}    

Then extend that class into a class that will be executed as a test:

class LoginSuccessfulTest extends LoginBase
{
    testSuccessfulLogin() {
        webtest(name:"Log in and go to page 2") {
            loginSuccessful()
            group(description: "Go to page 2") {
                invoke(description:"Go to page 2", url:"/page2")
            }
        }
    }
}

As you can see, the method loginSuccessful() from the parent class LoginBase gets called in the test method testSuccessfulLogin(). Again, this is not everything you need to execute the test, but it demonstrates the relationship necessary to get a repeatable sequence of steps included in a way that maintains the session.

The Straw Man as Web Design Process Motivator

A “straw man” in the most general sense is a sneaky kind of rhetorical argument based on misrepresenting an opponent’s argument [1]. In the design world, on the other-hand, a “straw man” is an artefact of some kind — like a page design, flow chart, storyboard, etc. — intended to initiate discussion.

According to Donna Spencer in her article Using a “strawman” for page layout design,

The strawman is created with the intent that it will be pulled apart and discarded. It is used to encourage discussion of the layout’s strengths and weaknesses and to generate better designs.

In my experience, a straw man is useful for more than a design facilitator. I’ve used straw men designs to help the development team build momentum; it wasn’t an issue of generating a better design, but of

  1. getting past the hurdle of back-end software engineers coming up with a UI design
  2. providing another perspective into the project’s requirements and expected behavior

Now, I’m not saying software engineers can’t design a good UI; I’ve worked with some world-class developers who just aren’t interested in the UI. They are elbow deep in the core code and like it that way. The straw man gives them something to implement without wasting cycles on front-end design.

On the other hand, a straw man design gives the engineers another take on the requirements and can help round out their understanding of what they should build and how they should implement the back-end design.

In short, the straw man design is a useful tool in your agile process toolkit.