Network, what network? That’s the mindset change you go through with the new breed of Web services.

Forget that you’re doing HTTP requests to a service running in Project Zero. If you want to call it from a command line you do this:

wget http://<ipaddress>:8080/services/app.groovy

You then realize that this service is available to anyone and from anywhere (assuming your pc is on a network), and you can run it from a command line, application code, or even a browser. Sweet.

Nadolig Llawen!

In my previous post, I mentioned I’ve started writing some scripts in Groovy. All was well until I wanted to persist data between tasks using JSON. The plan is to have a cron job that extracts data from a source and encodes it in a JSON file. I’ll then have a Project Zero application providing a service which when invoked would load the JSON data and return a summary of the data.

The good news… Project Zero has excellent built in JSON support through the zero.json.Json.decode and zero.json.Json.encode methods – which are amazing powerful and simple.

The bad news… When it comes to command line Groovy from groovy.codehaus.org, there doesn’t appear to be any built in support – bah!

So, using Groovy’s ability to use work with standard Java classes I trawled around for a Java JSON implementation. There’s a bunch listed on the www.json.org page, but having looked at a few none of them appear to be as simple as the Project Zero version.

The one that stood out was json-lib.sourceforge.net, but the number of dependencies it has on jars that have to be downloaded from external projects is mind boggling.

I tried importing the Project Zero jar files into my project to see if I could use the libraries they supply. But I soon discovered that it relies heavily on a running Project Zero environment. So no luck there either.

Surely it can’t be this difficult to have some simple JSON utility functions in Groovy. Right now I’m contemplating writing my own.

Having spent most of my time testing on the mainframe, I’ve spent little of that time actually writing command lines scripts for tests (other than some Unix System Services work). Now that’s not to say I’m not completely familiar with scripting since my primary work station has been running Linux for a considerable time.

However, recently I needed to a little more advanced scripting on my Linux machine. So it was at this point I thought “which scripting language should I pick up and use?”. Obviously there’s a decent selection to choose from: Perl, Python, Ruby, Groovy, others (including Rexx).

In the end I settled on Groovy due to my years of experience in writing Java applications, plus Project Zero provides Groovy support.

With my first script in mind I set down to write and learn on the fly. After getting my head around the new syntax I found myself making progress. Also it’s quite nice being able to drop down to the Java syntax and use utility classes that you know to exist and are already familiar with. I know I’m not writing the prettiest Groovy code at the moment, but the way I see it is scripting languages are there for getting things done. And in one afternoon I picked up Groovy, installed the Eclipse plugin for it, and created a working script to do exactly what I needed. I was happy.

I have this niggling thought though… if I get in to Groovy, will it confuse the hell out of me when I go back to pure Java?

Big Blue has just announced predictions for five big technologies in the next five years

Q: How do you go about testing a crystal ball?

A: Non-deterministic model based testing

More entries, more often… that’s the plan!!

Is there actually actually a name for this?

Wow, it’s been a while since I last posted an entry – is that how blogging works or am I supposed to do it every day . Maybe it’s all the Olympics watching that’s been going on!

Anyhows, I was looking for some quality criteria in Testing…

(more…)

Travelling to the Share conference (share.org) in Orlando I’ve achieved something I have never done before. I started, and finished a book during the flight. And proudly it wasn’t a small book of pictures, it was a book on Software Testing.

Having previously not given it much attention, the book was laying around my office for a while. Recently, I was on the hunt for some information and rather than go straight to the mother of all search engines, I decided to be old-school and check out the books on my shelf.

Flicking through a few I stopped on one that gave me exactly what I was after. In fact, it appeared to me that within its contents were lessons that every Tester should be aware of. It hit me, “Where has this book been all my life?”.

The answer was easy; “Sitting on a shelf”. After all, the book which was written by Glenford J. Myers has been in publish for the last 30 years.

It’s called “The Art of Software Testing”.

(more…)

In discussion with a friend it hit me that one of the biggest obstacles in going Agile is trying to convince people to deliver “little and often”.

What this means is that you deliver just enough code to get the feature working and leave out any “I’m gonna put this here for later use” code. You also accept that this may lead to re-writes of that code in later iterations. This implies that your code is not designed to be extensible from the outset.

On the opposite side is that of having a long delivery time for your feature. This gives you the flexibility of spending a considerable time up front designing the infrastructure to support any code that will follow in that release. Unfortunately with this approach you get the inherent problems of having a long waterfall release; little customer interaction and often it’s too late.

Now, what does this mean for Test? Well, going back to the first statement in this post. I think in the transition to Agile it can be really tough to break a developers’ mentality to write extensible code. Thus from a Test perspective you get elements of both extensible and time-to-market, meaning…

Too much to test in too little time.