Mariusz Cieśla

Automated UI testing with Jasmine and Zombie

2012-01-14T00:00:00+01:00

On my quest to be more able on the developer side of things, as well as my recently developed love to Node.js, I recently was looking for a good way to automate at least part of the user interface testing on a secret after-hours project. I don't need anything fancier than simple "It works if there's a button on the screen", but I expect to have quite a few of small cases when the project grows. Looking through the tools I could use, I finally settled with Zombie as a headless browser and Jasmine as a way to describe test cases (I tried Vows as well and I might actually go with it, but my first spike was done using Jasmine), which is pretty useful, since you can use Jasmine or Vows for server-side Node.js tests as well.

Tools

To start doing automated UI testing using only JavaScript - or in my case CoffeeScript, which I find easier to maintain, but harder to debug at this point - you will need a certain set of tools, which are:

Node.js - durr. Obviously. You can get Node.js here or, if you're using Mac OS X and Homebrew, simply brew install node
NPM - the Node package manager, soon to be built in the Node core, making this step obsolete. For now, unless you're from the future, you'll need to run curl http://npmjs.org/install.sh | sh to install NPM.
Jasmine and Zombie - with NPM, you simply run npm install jasmine jasmine-node zombie and it should work.
Should.js - if you find Jasmine matchers awkward, like I do, Should is an optional but useful step that makes them more humane.

Writing your first test

Assuming you're all set up, it's time to write your first test. In this example I will just use simple app that gets generated by Express. Install Express with npm just like the tools above (npm install express) and generate a simple app using express zombie-test. This will create a directory named zombie-test with a basic placeholder app running on Express.

To create your first test using Jasmine, you need to create a directory named spec inside your application directory that will hold all your tests. Inside that, create a simple test file - front_page_spec.coffee. Pro tip: for Jasmine to actually take your files into consideration, they need to have the word spec somewhere in the filename.

Our test will check if document loads, the title of the page is "Express" and if the welcome paragraph says "Welcome to Express", which it should. The test looks as follows:

describe "Front page", ->
    should = require("should")
    zombie = require("zombie")
    browser = new zombie.Browser()

    url = "http://localhost:3000"

    # callback function
    whenLoaded = (callback) ->
        browser.visit url, (e, browser, status) ->
            callback.call()
        jasmine.asyncSpecWait()

    # should open properly
    it "should open", ->
        whenLoaded ->
            browser.success.should.be.true
            jasmine.asyncSpecDone()

    # should have title set to "Express"
    it "should have title set to \"Express\"", ->
        whenLoaded ->
            browser.text("title").should.be.ok
            browser.text("title").should.equal("Express")
            jasmine.asyncSpecDone()

    # should have a welcome paragraph
    it "should have a welcome paragraph", ->
        whenLoaded ->
            browser.text("body > p").should.be.ok
            browser.text("body > p").should.equal("Welcome to Express")
            jasmine.asyncSpecDone()

That's it. I think code is pretty self explanatory, except maybe the callback function which is used to hold test from running until Zombie's browser.visit is complete.

If you need any more help, I recommend you going through docs for Zombie, Jasmine and Should.

Hello, Middleman!

2011-12-10T00:00:00+01:00

So, finally I managed to release something more interesting than just a Tumblr. If you followed me before, you probably know that I've been using Wordpress for ages and absolutely hated it, mostly due to all the maintenance required if you want to keep everything tidy and clean. Also, since I've been working with Ruby on Rails and similar technologies since 2008, I really hated the spaghetti-code mess of Wordpress templates. I tried several content management systems since then, but I never really settled with any because there was always something that was pissing me off.

Finally, I've decided to go for something written in Ruby and started looking into other alternatives for blogging, namely Nesta and - really low level - Jekyll and Middleman. Meanwhile, I maintained a Tumblr as my default, go-to blog.

I haven't really shared what's happening with my website since then, but I finally settled with Middleman as my blogging choice, for several reasons that I'd like to sum up in this post.

Learning new stuff

First reason why I even decided to look into non-CMS alternatives for blogging was simple - I love to hack around and learn new stuff and freedom given to you by "engines" like Nesta, Jekyll or Middleman is just amazing - if you want your templates to be Haml, you just install a Ruby gem and add one line to the setup. If you want your stylesheets to be Sass - same thing. Love that.

I finally settled with Middleman because it's dead simple. There's nothing there except one config.rb file and a Gemfile for Ruby gems that your blog requires. You can do everything from the text editor level, which is really awesome if you like simplicity.

Pure blogging fun

Another thing that I love in those minimalistic blogging solution is the fact that they leave you with nothing but template engine of your choice and text files for writing posts. There's no database, no WYSIWYG editors, nothing like that. That means you can write your posts on the go in any text editor (or Writer, like I do) and then save it as a Markdown file. When it comes to control over your files, there's only one level below, and that's writing your blog in pure HTML, but I personally love Markdown and wouldn't replace it with HTML.

Unlimited power

Since you're writing your blog in Markdown into text files without database, good idea is to keep your files in a repository, just like you would keep your code. While that might be a bit tedious for a non-developer (even though I know at least two people who have absolutely no tech background and they are blogging with a git-based solution just fine), but gives you power of a full-fledged version control system behind your blog. That means merging, branching, reverting and all the awesomeness that comes with it. As I said before, if you like fiddling around with your tools and you're a developer (so you know how to go about a version control system anyway), it's a perfect combination.

Wrapping up, I highly recommend switching to a simple, non-CMS solution if you're a developer. If you're not a developer, but you like to learn new stuff, I recommend it as well. If you need any help or inspiration, you can find the source of this very blog on my Github and all the docs you need to get you up and running at the Middleman website. If you have any specific questions or tips regarding my code, feel free to reach me on Twitter as this blog doesn't have any comment system and it might happen that it won't, since I think everything these days can be done via Twitter.

Happy hacking!