Automated functional testing with Javascript using Mocha and Selenium [Part 2]

(This is the second installment in my series on the basics of how to use Selenium and Mocha to perform functional tests on your web applications. For the previous article, click here.)

In today’s post, we’ll using Mocha and Selenium to test a basic sample application. Before getting into that however, you will need to download a few things:

Step 1: Install Node JS

If you haven’t already, install Node JS by following the instructions on http://nodejs.org/.

Step 2: Download Selenium

Selenium is a tool that automates web browsers, allowing us to run our functional tests against a real instance of a browser. It currently supports a number of versions of Internet Explorer, Firefox, as well as Google Chrome and Opera (although some of these require third party written code – for a full supported list of browsers go to here). At the core of how Selenium works is the Selenium Server, which is responsible for the execution of automation commands to the browser. A Selenium client can then connect to the server, and instruct it to perform a variety of different actions (ie. clicking a button, going to a URL, etc) or to retrieve information about the current state of the browser (such as using CSS selectors to retrieve elements, inspect text, and so on). The real advantage to this is that it allows for language specific clients (or WebDrivers) which allow for automation scripts to be written in a developer’s (or tester’s) language of choice, be it Ruby, Java, Python, C# or now, thanks to the experiemental WebDriverJS client, Javascript.

For the purposes of this article, you will to download the Selenium Server from the Selenium downloads page, and assuming that you have Java installed, you can then fire it up by running -

java -jar <path to the Selenium JAR file>

You should see the Selenium server load up, and be ready to start serving tests.

Step 3: Get the sample application

Now that we’ve got the base dependencies installed, you can either checkout my example project from my GitHub repository, or create your own simple application to test. My sample application is a very simple Express application running on Node, which we’ll be testing using Selenium and Mocha.

Before running the application, you’ll first have to install the module dependencies. This is done through the use of NPM (Node Package Manager – an exceptional tool for managing dependencies which is included with the Node JS installation) by running -

npm install

Once the dependencies, you can start up the application server by running -

node app.js

Navigate to http://localhost:3000 and you should see the application running as in the image below.

It is a very simple ‘Library’ index application – it consists of a home page, a books page with a list of books, and an authors page, with a list of authors. Links on each of the pages control the user’s navigation.

Before we get onto writing the tests proper, there were a few modules that were installed by NPM that are worth knowing about at this point.

Mocha

Mocha is an exceptional test framework for Node.js (as well as browser based) testing developed by TJ Holowaychuk – author of the Express web framework for Node. It allows for a comprehensive suite of test functionality and reporting that makes writing tests almost enjoyable – not quite, but about as close as you can get! While I have indicated that Mocha is to be installed as a development dependency of my sample application, you can also install it manually using the following command -

npm install mocha (or npm install -g mocha to install to the global NPM repository)


Chai

Once we have Mocha, we can also choose an assertion library to allow us to evaluate our test assertions – my personal favourite is Chai, which allows for BDD/TDD style assertions and works well with Mocha. Chai can be installed via NPM as well, using the following command:

npm install chai 

WebdriverJS

As mentioned in my first article, to communicate with the Selenium server from Javascript, you have a number of choices. The first is to take advantage of the WebDriverJS web driver for Selenium. In order to use this driver, you will have to checkout the Selenium source code from the SVN repository, and then build the WebDriverJS by following the instructions on the wiki.

The second one I’ll mention, and the one that we will use for the remainder of this article, is the webdriverjs NPM module written by Camilo Tapia, which utilizes the Selenium JSON Wire Protocol to communicate with the Selenium server.

There are few reasons as to why I chose the Camilo’s module over the standard WebDriverJS module. Primarily however, I believe that tests should be as easy to write as possible, and while the same functionality is present in both, Camilo’s module makes writing tests, and adding custom functionality a much more pleasant experience than the verbosity involved with working with the standard WebDriverJS module.

Step 4: Run some Selenium tests

So now that we’ve got our application all up and running, let’s run some tests to test that it’s working correctly. We’ll run one of the tests that’s included with the sample project – simple_test.js. This test will simply navigate to the page, and test to see if the title equals ‘Library’. To run the test, use the following command from the root directory of the sample project:

mocha tests/simple_test.js -t 30000

You should see the application fire up in Firefox (this can be configured to other browsers), and you should see Mocha complete the test successfully. If you find that Firefox takes a while to start up, and Mocha times the test out before completing successfully, you may have to increase the value of -t in the above command. (the value is in milliseconds so 30000 = 30 seconds)

Let’s take a look at the guts of this test to see what’s happening:


before(function(done) {
// Add some helper commands
client.addCommand('hasText', function(selector, text, callback) {
this.getText(selector, function(result) {
expect(result.value).to.have.string(text);
callback();
});
});
done();
 });

The before() function in Mocha allows us to setup code that runs before the tests are run. In this instance, we are using it to add a custom command to the webdriverjs client to allow it to have a .hasText function that will use Selenium to get the text of an element on the page, and then use a Chai assertion to assert whether it is the value we expected or not.

beforeEach(function(done) {
  // Navigate to the URL for each test
  client.init();
  client.url('http://localhost:3000', done);
});

The beforeEach function get’s executed before each test is run. In this case, it sets up the webdriverjs client, and instructs it to go to the application URL before actually starting the test.

it('should be able to view the home page', function(done) {
  this.timeout(10000);
  client.hasText('#title', 'Library');
  done();
});

The code above forms the actual content of the test. The this.timeout function instructs Mocha that it should fail the test if it hasn’t finished within 10 seconds. We then use the .hasText function that we added in the before() function to assert that the title element has the text ‘Library’. If it didn’t have the matching text, the test would have failed.

afterEach(function(done) {
  client.end();
  done();
});

After the test has finished (or failed), Mocha runs the afterEach function, which we use to clean up the Selenium sessions that were created over the course of the tests.

And that’s it – a Mocha test that uses Selenium to test a web application in the browser!

What next?

This has been a very simple demonstration of Mocha and Selenium and of course, any real test would be expected to do things like clicking links, uploading files, waiting for elements to appear/disappear – all of which is possible. For starters, if you are interested, you may wish to check out the slightly more complicated page_test.js file in the repository, which tests the navigation of the sample application.

Alternatively, additional reading resources can be found at:

If you have any questions, please feel free to leave a comment below and I’ll attempt to get back to you when I can.

If this article has interested you, you may wish to follow me on Twitter (@noehlman), or you may wish to browse the random collections of code on my GitHub repository.

An Aside: Asteroid Mining? I want in!

Let me start by apologising – today’s post was meant to be a continuation of my series about automated functional tests in Javascript using Selenium and Mocha, and for those who are interested, never fear, I shall be attending to that in my next post. Today however, something more important has come along, and that is this news article about James “If it’s not 3D, it’s not a movie” Cameron, Larry Page and Eric Schmidt (of Google fame), as well as other people teaming up to back a new company named Planetary Resources. Generally, I don’t follow corporate news that closely, but when the rumours about this new company centre around the belief that it will be attempting to mine asteroids using robots, I get a little bit excited… and by a little, I mean, almost giddy.

One thing to realise about me is that I love space – anything about space. Ever since I was a kid it has fascinated me endlessly – when my younger brother and I weren’t sending our teddy bears off on astronautic adventures, I read science fiction books ceaselessly – it didn’t matter if it was a free self published, D-grade space opera novella off of Amazon, I’d still read and probably enjoy it merely because it detailed the adventures of people who are living, breathing, and making something of themselves… in space. As I got older, I read articles about space (even the technical ones, it didn’t matter if I didn’t understand them), played every space game I could my hands on, dreamed of ways to make space travel a reality (as a youngster, I once designed a space craft that would travel by scooping up space dust, and shooting it out of the back at high velocities to impart acceleration. A good idea, apart from the fact that a better idea had already been thought of) and wondered why it was so hard to build a space elevator, or colonise the moon. So it’s pretty safe to say that when it comes to space, I’m a bit of a fan.

So the idea of that a company is could actually be attempting to mine asteroids is huge, and there a number of reasons, beyond just the cool factor, that this excites me so much.

The problem with this picture? We can't get back

Firstly, NASA (and other government space agencies) have dropped the ball. Just under 43 years ago, on July 20, 1969, a truly momentous thing happened – Apollo 11 – with Neil Armstrong and “Buzz” Aldrin aboard – landed on the moon. Humanity had set foot on another world and the world would never be the same – space was now the next frontier. Except, apart from another 5 moon landings, it all just kind of… stopped. Now, before I start getting slammed by people claiming all the things NASA (and the other international space agencies) have done since then, let me clarify. These agencies have done some incredible things since then, such as the Voyager probes, the Mars Rover missions, the Hubble Space Telescope, not to mention the International Space Station (which is incredibly cool – for those who haven’t seen it, I highly recommend watching the tour of the ISS by Mike Fincke – it shows the real scope of the station). I’m not trying to diminish the enormity of these technical achievements, but when I say things kind of stopped, I mean that government controlled space programs seemed to lose the desire to expand the space frontier. Sure, the USA had proved that man could reach the moon, but there was no follow on. No moon base missions, no attempts to build orbital infrastructure to support future space efforts – in fact, in the 40 years since Neil Armstrong set foot on the moon we have not only not repeated the feat, but we have even lost the ability to do so. Instead, humanity remains stuck within the close confines of the Earth, sending remote controlled toys to take pictures of other worlds, and take dirt samples. Interesting and necessary – absolutely. Revolutionary and inspiring – not really.

What we needed (or rather that should be phrased as “What I wanted”) is a space program that had a forward direction, a vision, and a goal to expand humanity’s borders beyond the Earth. Since the space race started to take off, it inspired generations – millions of people – that the impossible was possible. What we’ve seen lately is that the impossible remains just that, and what’s the point of trying – mainly caused by a lack of funding from governments, and a misunderstanding about just how much value a space program can bring to a nation and the world. (As an Australian, it disappoints me just how little presence my country has in space – I know we’re small, but we’re innovators!)

The reason Planetary Resources and it’s asteroid mining rumours cause me hope is because while the government space agencies have slowed, in the past decade commercial endeavours designed to transform space into a commercially viable operating space have been gaining significant traction. Such enterprises, such as SpaceX, who have been conducting profitable operations since 2007, and are just about to take on the first COTS resupply mission to the International Space Station; Virgin Galactic with their sub-orbital tourist flights, and Bigelow Aerospace with their very cool expandable space stations (using technology originally developed by NASA) are really pushing ahead with making space a viable reality. As more and more players get involved in the space game, more and more money is going to be put into research and development of space related technologies and particularly with commercial enterprises being involved, there is a more solid push to get actually produce something at the end of it. After all, theories are all well and good, but theories aren’t going to make you any money. As someone interested in space, I’m in favour of this. Why? Because I want to see that cool engine design actually powering a space ship, not sitting in a scientist’s notebook gathering dust.

This asteroid is just ripe for the taking

The other benefit of having commercial entities involved in space is that they are interested in something that governmental space agencies haven’t been – and that is space related infrastructure. If you are a commercial operator looking to exploit space for financial gain, you’re going to need the supporting infrastructure to help you do that – something that we are already starting to see happening around the world. Richard Branson’s Virgin Galactic, for instance, bankrolled Spaceport America to support their future space tourism operations, whilst their spacecraft provider, Scaled Composites has invested in their own manufacturing facilities designed to construct spacecraft. The true is same of any of the other major players in the space technology sector – SpaceX has constructed their own launch facilities and supporting infrastructure as well. At the moment, the majority of this infrastructure is on Earth, but with the cost of launching payloads out of Earth’s gravity well, one would imagine that these companies, and others, will be looking to expand this infrastructure into space as well – something that a resource company dealing in mining asteroids, such as Planetary Resources, would be ideally placed to help deal with. Which brings me to the second reason I’m excited about Planetary Resources and asteroid mining.

We need access to raw materials in space. Let’s face it – building stuff on Earth and shooting it up out of our gravity well on the back (or top of) of a liquid-propellant rocket is not real economical. At the moment, it costs upwards of a $100 million dollars to launch a few hundred kilograms of cargo. There are three possible ways of dealing with this:

1) Continue on as we are – keep spending huge sums of money for relatively payloads.

2) Develop a cheaper way of getting things to orbit – be it a cheaper, more efficient rocket; a space elevator; or a giant catapult.

3) Reduce the quantity of goods needed to take into space.

As you may have guessed, I’m not the biggest fan of option 1, but I am in favour of pursuing options 2 & 3. Asteroid mining has great potential to help with reducing the dependency of space bound infrastructure on Earth bound industry. By having access to raw materials in space, without the prohibitive cost of transporting it from Earth, means that manufacturing becomes a viable prospect. Sure, it requires a substantially higher outlay of financial and technological capital initially to set up an basic industrial capacity in space, but once it is there, the possibilities just explode, particularly if that industrial base is able to create additional industrial capacity.

Need a new one? Build one up there from raw materials

Need a new space station? Construct as much of the heavy structure in orbit from resources already up there, and save the heavy Earth lifting capacity that would have been used to lift large chunks of steel for the really critical bits. Need a spaceship to go to Mars? Forget about needing to design it to withstand an Earth launch, make it in space for travel purely in space – resulting in a substantially cheaper, simpler design. Need to build a hydroponics station to support growth of food for hungry spaceworkers? Ditto. Plain and simple – an industrial capacity in space means that the world is literally, at your fingertips. Needless to say, the first entity (be it government or commercial) with this sort of capacity is going to have an edge that will be hard to overtake for a long time (a point which leads to an interesting discussion on the nature of laws, ownership, nationality, and the role of corporations in space – but that’s a discussion for another time.) This sort of capacity starts with access to those raw materials, and if Planetary Resources are serious about asteroid mining, and can actually pull it off, then you and I may live to see a future where humanity has moved to living beyond this planet – and that is something incredibly exciting.

If you are a fellow space nut; a NASA engineer with an axe to grind about my article; or someone with something to say – feel free to leave a comment below.

If this article has interested you, you may wish to follow me on Twitter (@noehlman), or you may wish to browse the random collections of code on my GitHub repository.

Automated functional testing with Javascript using Mocha and Selenium [Part 1]

Over the past few years, I’ve become a firm believer in the value of automated testing, to such a point that I would never contemplate starting a serious project without at least some form of automated testing built in (be it unit testing, or functional testing). Like most, I’d say that my passion for automated testing has not developed from a sheer love of writing tests (although – if that’s you then you are a lucky person!) but rather because of a number of other things – ie. I’m passionate in my dislike of having to test things manually; passionate in my desire to deliver a quality product; and passionate about being able to refactor code without that fear of unknowingly breaking the entire build.

Fortunately for me, my interest in automated testing (fuelled by a automated testing pioneer colleague of mine) arose at the same time as feasible testing tools – such as JUnit for unit testing, and Selenium and Watir for functional testing – started to gain some serious traction, particularly in the J2EE world.

The moment you realise you broke the build

Given that I was then working as a contractor on a large J2EE web application, this allowed for me to really see the how impressive the benefits of automated testing really are (which, and I won’t go into detail here, have serious benefits to the bottom line of a project, robustness of the product, development time and general developer happiness). So much so, that when I moved full time into the world of Javascript at the start of this year I started looking to see what was on offer in this cutting edge new space.

In short, what I found was this – Javascript (particularly Node.js) has a lot of support for unit testing, such as the exceptional Mocha testing framework, but little support for functional testing. While this wasn’t a major issue given the fact that functional testing occurs in the browser, and so it’s just as easy to write tests in Ruby (or C#/Java/insert supported language here) and still get the same outcome. However, call me old fashioned, but if I’m writing a server side application in Javascript, with a client side Javascript application talking to it, being tested by Javascript unit tests – then it stands to reason that my functional tests should be Javascript as well – so imagine my delight when I found WebDriverJS, which provides a Javascript driver for Selenium. More to the point, after a bit of experimentation it became obvious that the WebDriverJS could be easily worked in with Mocha to provide a nice, easy to use (and pretty!) functional test suite.

So over the course of the next couple of days, I’ll be posting a few articles detailing some of the things that I’ve discovered while investigating the functional testing possibilities with Selenium and Javascript through the creation of a sample project. If you’ve had any experience using Selenium (or Watir) with Javascript, or have come across any great resources, then I’d love for you to leave a comment below.

For those interested in having a dig around while waiting, here are some of the resources that I’ve been using:

If this article has interested you, you may wish to follow me on Twitter (@noehlman), or you may wish to browse the random collections of code on my GitHub repository.

Hacking on Browser Quest

tl;dr; Hacked on BrowserQuest – results available at http://208.115.237.122. For details, read on.

As you may have heard, last week Mozilla released Browser Quest, which is essentially a technical demonstration of web gaming – in this case, Browser Quest is a massively multiplayer HTML5 browser based game that uses Canvas for rendering, WebSockets for network communication, and Node.js for a back end server. If you’ve played Browser Quest, or had even a brief look at the code, you’ll already understand that Mozilla hasn’t set out to make Browser Quest as the next World of Warcraft, but rather to spark the ideas and creativity in a field that has been a little lacking up until now – the field of open technology (native to the browser) HTML5 games.

Best of all however, they open sourced all the code for the game (minus a few audio files) which means, if you’re like me, you can get a little bit of a buzz out of hacking together a little bit of a game. After all – making web apps is fun, but making web app games is much more so, so the team at Sidelab thought this was an ideal project for one of our occasional hack days.

Taking a look into the code, we found that there are some bits that are extremely well written, particularly on the client side. The Renderer class, which renders the tile based map onto the screen, does a lot of things well (I particularly liked the use of multiple canvases to provide the foreground, background and sprite layers – it makes a lot of sense!). Likewise, the WebSocket communications, despite some rigidity which is to be expected in a technical demonstration, makes a strong case for the ability of WebSockets to be realistically used in browser based gaming – something that I had before been sceptical about.

On the flip side, the code was proved to be not inherently extensible, and the use of some odd coding conventions (possibly for speed reasons) on the server side, such as not using events – something which Node.js prides itself on – seemed to be a little strange. But on the whole, it looked like an ideal platform with which to get something up and running quickly.

For my part, my desire was to provide a little more meat to the game – a bit of atmosphere, without affecting the game too much, and hopefully creating something I could later translate to a different coding project. In order to do this, I decided to implement an Orchestrator, an object that is able to observe the each of the WorldServer’s that the Node.js server creates, and apply any number of configurable Orchestrations to the world that could receive and publish events, and thereby, allow the WorldServer to be extended without requiring significant modifications to the original BrowserQuest source.

The test of this was the creation of a Day/Night cycle orchestration that causes the world of BrowserQuest to shift between a bright glorious day, and a dimly lit night filled with ravenous, aggressive bats, a change which, along with some other small client side and server side tweaks, can be seen on my own hosted instance of Browser Quest at http://208.115.237.122. (a small aside – again, massive kudos to Mozilla for releasing everything you need to deploy your own server)

Whilst this server plays very much similar to the original BrowserQuest (my attempts to build in an overarching attack by monsters didn’t realise as much gains as I’d hoped in the small amount of time I spent on it), what it has sparked in me is the realisation that finally native browser based games are possible; are a reality and now that someone else has gone to the effort of proving it for me, are something that I can see myself sinking my teeth into – and for that, you’ve got to give Mozilla (and the guys who made the game, Little Workshop) a lot of the credit.

For those who are interested in playing around with my Orchestration changes for BrowserQuest – be my guest! The source is available in my fork of the BrowserQuest source in my GitHub repository.