I mentioned earlier a solution where Eclipse would run all my Python tests when I save a file. This is very convenient when using TDD in languages that can run tests fast. However that solution is tied to Eclipse and as I like Vim more and more I stand without an option to automatically run the tests as I code.

This feature is quite similar to AutoSpec in Ruby. So I figured there would be some solutions available for Python already. Looking around I found this to be the best possible solution right now. However that solution doesn’t handle nose tests, and the project I’m working on is using nose-gae to do the testing. So I needed a solution that worked on Windows and could run nose tests with nose-gae.

This started to annoy me, especially since it would be quite easy to implement it in .Net and have it work with the command-line to add support for any type of action that needs to be run on a file change.

So I wrote a little tool, which I call: OnChange

It’s a command-line application that watches the current directory and any directory under it for file changes. When a change occurs it will file a specified program, in my case, run my tests.

It also has support for parsing the output of the command to run, so with regex patterns you can add “reactions” to how the executed program is run. This allows me to signal Growl for Windows to bubble up “tests fail” or “tests pass”.

I also added a filter option so it will only react to changes in certain files.

This is how I set up my onchange program to run tests and signal pass or test automatically.

onchange -f *.py -r "^FAILED.*$:fail.bat" -r ^OK.*:pass.bat runtests.bat

This command line will cause OnChange to watch for changes to *.py files (-f flag). It has two reactions set up on that matches on FAILED test output and in that case runs the fail.bat command, and on that matches the OK test output and in that case runs the pass.bat command. The last argument to the call is my runtests.bat file. The runtests.bat file will execute the nose tests, and in an extension also execute my Jasmine tests in the same project.

The source for OnChange is available on GitHub. Feel free to help add to it if you’d like.

I’ve been working extensively with JavaScript these past weeks. As I mentioned earlier I wanted to try out Jasmine and I definitively got the chance. I’ve been using it for all my testing needs these last weeks, and I love it.

What do I like about Jasmine?

• The ability to nest describe statements
• the splitting of specifications into several files
• the output structure

What I do not like

• At times failing tests can give cryptic error messages in Chrome, since Jasmine will trap the errors inside it’s own execution. This can cause the stack trace and the error messages to mess up.

Let’s see some examples then:

describe("A view holder", function() {
  describe("when adding a view", function() {
    it("it should add the view's element to the holding div", function() {
      loadFixtures("/specifications/spec/holder.html");
      var holderDiv = document.getElementById("holder");
      var docHolder = new ViewHolder(holderDiv);
      var template = "<div>test</div>";
      var doc = new View({template:template});
      docHolder.showView(doc);

      expect(holderDiv.innerHTML).toContain(template);
    });
  describe("when removing a view", function() {
    it("the previous view is displayed", function() {

        var docHolder = new ViewHolder();
        loadFixtures("/specifications/spec/holder.html");
        var holderDiv = document.getElementById("holder");
        var docHolder = new ViewHolder(holderDiv);
        var template = "<div>test</div>";
        var doc = new View({template:template});
        var doc2 = new View({template:template});
        docHolder.showView(doc2);
        docHolder.showView(doc);
        docHolder.popView();
        expect(doc2.element.style.display).toNotEqual('none');

    });
  });
});

This is an example of a specification I wrote for a view system I’ve developed, the output looks like this:

I added the following snippets to SnipMate so now I have a really nice flow when writing my specifications:

# Describe
snippet desc
  describe("${1:description}", function() {
    ${2}
  });
# it
snippet it
  it("${1:does}", function() {
    ${2}
  });

Jasmine is now my testing framework of choice for JavaScript testing.