Tag Archives: software-development

Executing Gatling tests from Node.js

So, I’ve been playing with Gatling quite a bit recently. It’s a really neat open source load testing tool.

Anyway, what I wanted to do was to have a remote instance that I could trigger a Gatling test on and then get the results back, all over http. Node.js seemed the obvious lightweight solution to do this in….

Now, how to trigger a Gatling test from Node.js. Well, there are a few complexities but generally it is not too bad.

Executing a Test

Gatling runs as a command line tool, so the first step is to use an NPM package called “sh”. This is a package that allows execution of commands and executes a callback on completion.

By default Gatling will run in an interactive mode, awaiting user response to determine the tests that should be run. Obviously this is not viable when running headless so we need to add some switches to the base command

-s class.classname [where class.classname is the class of the test you wish to run]
-sf path/to/script/folder [this can be avoided if scripts are stored in default Gatling directory]

Executing the Gating command with these two switches via the following line of node will successfully execute a test and execute the callback script on completion

var command = this.config.gatlingRoot + ' -sf ' + this.config.rootfolder + ' -s ' + this.config.testClass;
sh(command).result(function(){test.completeTest()});

Capturing the Results

Executing a test though is no use without being able to gather the results and this was slightly more of a challenge. Gatling creates a new folder for every test execution, by default this will be another folder within its standard results folder. The issue this created was that there was no way, as far as I could tell, of getting the details of that folder from the command line response.

What you can do however is to define the root folder for the results in the command line by adding the -rf switch.

-rf path/to/results/folder

Gatling however will still create a subfolder within that for every test run. This where NPM comes to the rescue again with the “fs” package which allow monitoring of a folder and raising of an event on any changes. Therefore you can create a folder specifically for the holding of your test results then execute a test and be confident that the next event on that folder will be the creation of the results folder. The fs callback includes the name of that folder.

function setupResultFolder(test){
var resultfolder = test.config.rootfolder + "results/"
fs.mkdirSync(resultfolder);
fs.watch(resultfolder, {
persistent: true
}, function(event, filename) {
test.setResultFile(filename);
});
return resultfolder;
}

Then to get to the results you can just access the relevant files within that folder. I was only interested in the raw results so I was looking at simulation.log.

Notifying of test completion

To finish off I just added a simple event that is raised when the test is complete

this.completeTest = function(){
this.complete = true;
this.emit("testComplete");
}

Complete code

The complete code comes in at <50 lines.

var fs = require('fs');
var sh = require('sh');
var events = require('events');
var eventEmitter = new events.EventEmitter();

var GattlingTest = function(id, config) {
events.EventEmitter.call(this); 

this.id = id;
this.complete = false;
this.resultfile = "";
this.resultfolder = "";
this.config = config; 

this.start = function(){
var test = this;
this.resultfolder = setupResultFolder(this);
var command = this.config.gatlingRoot + ' -sf ' + this.config.rootfolder + ' -s ' + this.config.testClass + ' -nr -rf '+ this.resultfolder;
console.log(command);
sh(command).result(function(){test.completeTest()});
}
this.setResultFile = function(resultfile){
console.log("resultfile for " + id + " set to " + resultfile);
this.resultfile=this.resultfolder + resultfile + config.resultFileName;
console.log(this.resultfile);
}
this.completeTest = function(){
console.log("complete");
this.complete = true;
this.emit("testComplete");
}
this.results = function(){
return fs.readFileSync(this.resultfile, "utf-8");
}
}

GattlingTest.prototype.__proto__ = events.EventEmitter.prototype;
module.exports = GattlingTest;

function setupResultFolder(test){
var resultfolder = test.config.rootfolder + "results/"
fs.mkdirSync(resultfolder);
console.log("Tracking ... " + resultfolder);
fs.watch(resultfolder, {
persistent: true
}, function(event, filename) {
console.log(event + " event occurred on " + filename);
test.setResultFile(filename);
});
return resultfolder;
} 
Advertisements

Leave a comment

Filed under Code

Progvember – a month of coding in November

A year ago I came across the National Novel Writing Month which is basically a challenge to aspiring authors to dedicate themselves to complete the writing of a novel within a month. This seemed like a good challenge; after all, we all have a novel within us somewhere. However, what I like doing better than writing a novel is computer programming. Therefore my novel kept getting pushed back by bits of development I was doing.

At the same time I was writing an iPhone app for my son for his Christmas present. This was good for two reasons – 1) it was a present for him and 2) it was a chance to finally do some different things I had been wanting to try out in Objective C. So, I had the project, I had the motivation and most of all I had a fixed deadline – Christmas was not going to be pushed back because of an incomplete piece of software.

Like most developers I have a list of new technologies, languages and patterns that I want to try out and just like the great novel that is inside us all there are always more important things to be done. There is no defined project and no defined deadline so nothing really gets done.

What I liked about the “nanowrimo” concept was that it created a focus, it created a deadline to work towards and it created a sense of community of other people all working towards the same goal. So why not create something like that for development?

Hence, I came up with the concept of Progvember (programming in November – get it?!). This would be a month where developers set themselves a challenge to define and project and complete it – to take some of the ideas that have been there for a while and set a deadline to get them done. November seemed a good time of year to do it – long dark nights, cold, wet weather (apart from our southern hemisphere Provemberers) and all that most people are doing is sitting in, or maybe growing a moustache for Movember.

On the back of this I wanted to also create a sense of community of other developers who are also setting themselves the same challenge, and also to create a forum where people can ask/offer to help on other people’s projects.

And so I have created Progvember.com. Anyone is welcome to come and sign up.

Leave a comment

Filed under Progvember

The Joy of Performance Improvements

I think that most developers get in to development for one of two reasons – they like solving problems, or they like building things. For me when I got into it is was the latter. I loved the fact that I would build things that people would then use (admittedly, I have often also built things that people didn’t use).

However as my career has progressed I have realised that by far a more enjoyable and satisfying element of development is working on performance improvements.

Since I moved into management I don’t get to work on development as much as I would like (which would be all the time), but recently I have built a system from scratch to delivery while also working on some performance improvements to an area of a site that had been declared “not fit for purpose”.

Comparing the two experiences, there was just no comparison. I’m talking about the experience of taking a failing system, investigating, manipulating, testing, making amendments, re-testing, assessing the impact of tiny changes, assessing the likely impact of large changes, finding out why elements that perform independently do not perform in combination, re-testing again, making another small improvement, re-testing, re-investigating and repeating it until performance is acceptable – then doing a few more rounds until performance is awesome. This was soooo much more enjoyable and rewarding than just building a system from scratch.

I’d recommend any developers to try to get involved in this side of development. That’s why I set up a performance management and improvement company!

By the way, if anyone is interested, the outcome of the performance improvements was taking a process that was taking 45 minutes to run down to running in 3 minutes. The target was 10 minutes.

1 Comment

Filed under Opinions

6 Rules for Good Specifications in Software Development

In recent months we have overhauled the Intechnica development process to use a lot of the BDD – Behaviour Driven Development –  and “Specification by Example” (http://gojko.net/) processes and tools for specification definition. As such we have defined the 6 rules of good specifications:

 
1. Communication between client, BA, QA and developer:
The more all of these people talk, and the earlier they are involved in specification stage, the better.

2. Don’t define user experience and business functionality in one place.
It leads to repetition and confusion. It also tends to lead to underlying systems designed around the UI rather than the business domain.

3. Illustrate all business logic with examples
…not with wordy descriptions.

4. Illustrate all UI with annotated pictures
…or ideally full HTML prototypes.

5. Specifications must be testable to form objective acceptance tests.
Tests should be automated and built into your continuous integration process.

6. Specifications should be living documents
…and evolve into the living documentation of the system.

View some of Andy’s presentations about software development on Intechnica’s SlideShare

4 Comments

Filed under Opinions