Another day, another name

Yesterday I wrote an article about JSTestSan. Today, however, I decided to move the repo to our Fingertips account and also change its name to “Headless Squirrel”.

The command-line tool is still called jstest, only the name and locations were changed. I’ve updated the previous post to reflect these changes.

Note that the name and locations of this project have changed. The new name and locations in this article have been updated to reflect this. See the Headless Squirrel article for more info.

A OS X command line tool to run JavaScript (Prototype) unit tests from the comfort of your terminal.

Why?

Recently I came across an article on testing JavaScript outside the Browser, which talks about running tests written in Ruby against your JS libraries.

At the office we loved the idea of being able to run our JS unit tests together with all other (Rails) tests. However, not in the way the aforementioned article suggests.

Now I know the title of the article explicitly says “outside the Browser”, but running outside of a real browser seems a bit pointless to me. I’d rather run them inside an actual browser, as we are currently doing by hand on Safari. And also write them in a format that would allow us to run them by hand on any browser, ie HTML/JavaScript.

Since we’re all on Macs, my Cocoa flags where quickly raised. Especially on the use of WebKit, which, as you might know, powers Safari.

I fired up my favorite text editor and wrote a prototype. Happy with the results I decided to re-write it for real this weekend. Also because I needed something noteworthy to write about on this new blog ;-)

Install

The source is available as either a Ruby gem, or directly from GitHub. To install the gem:

$ sudo gem install Fingertips-headless-squirrel -s http://gems.github.com

Usage

Headless Squirrel comes with a command-line tool, called jstest, which you can feed HTML files that run Prototype unittest.js test cases.

For instance, let’s run the Prototype test suite which comes bundled with the Headless Squirrel source code (updated slightly):

$ jstest test/regression/prototype/unit/*_test.html
...................................................................
...................................................................
....F..............................................................
...................................................................
...................................................................
.....................

  1) Failed:
testViewportDimensions (Unit test file | Dom | default template | 2009-04-11 15:28) [test/regression/prototype/unit/dom_test.html]:
Failure: NOTE: YOU MUST ALLOW JAVASCRIPT TO RESIZE YOUR WINDOW FOR THIS TEST TO PASS
expected: <50>, actual: <0>
Failure: NOTE: YOU MUST ALLOW JAVASCRIPT TO RESIZE YOUR WINDOW FOR THIS TEST TO PASS
expected: <50>, actual: <0>

Finished in 18.127608 seconds.

356 tests, 2246 assertions, 2 failures, 0 errors

That should look familiar to people using Ruby’s Test::Unit.

I haven’t added a Rake task helper yet, but the following should get you going for now.

namespace :test do
  desc "Run the JavaScript unit tests in public/test"
  task :javascript do
    puts "Running JavaScript tests:"
    sh "jstest #{Dir['public/test/*.html'].join(' ')}"
  end
end

task :test do
  Rake::Task['test:javascript'].invoke
end

Note that the last task does not override the test task that comes with Rails, rather Rake will append the block to the blocks of the existing test task. So when the original task finishes your JS tests will be ran.

Conclusion

I’m pretty happy with the current results. But as you can tell, from the output of running Prototype’s test suite, there’s still a problem, and I’m sure there are more like it.

In this case the problem is that there’s no actual window object (NSWindow) associated with the WebView instance, which is why the poor bugger can’t adjust its dimensions. People shouldn’t be resizing the users windows anyways, so I don’t worry about this problem too much ;-)

As stated earlier, Headless Squirrel currently only works with Prototype’s unittest.js, because that’s the combination we are currently using at the office. However, it should be easy enough to add support for other test frameworks. Let me know if you do so.

A OS X command line tool which executes commands when a file, or a file in a directory, is modified.

Thanks to Manfred Stienstra for the project’s mascotte image. Kikker means “frog” in Dutch.

Why?

Not so long ago I had to work on some text formatted as Textile. For this task I had to go back and forth to my text editor and terminal to edit and render the text as HTML. This started to get tedious pretty fast, so being the Ruby and Cocoa head that I am, I quickly whipped up a simple, purpose agnostic, command-line tool which uses the FSEvents API (OS X) to watch for file changes.

I just love how easy it is to write small" tools with Ruby and Cocoa that do seemingly “big” things. For another example see "the next blog post.

Install

After some weeks of usage, and finally implementing the ability to watch multiple paths, I can now say it’s definitely usable. Get it:

$ sudo gem install alloy-kicker -s http://gems.github.com

Now go kick some stuff!

If you want to checkout the source you can do so on GitHub.

Example

Say you’d like to run a Ruby test case every time either the library file, or the test case file is saved. This can be accomplished with the following command:

$ kicker -e "ruby test/unit/article_test.rb" **/article*.rb

From now on whenever you save any file which matches the glob expression, the test case will be ran.

There’s also support for Growl notifications and click callback handlers. See the README for more info.

So know you know. Go wild!

I finally found some time to move some personal web applications to my slicehost vps, which has only been running pasternak up till now… What a waste of money.

So here comes an end to that situation!

Return of the Mac and web developer

I’m back online, so step 1 has been taken care of. Now comes step 2, the hard part, keeping it up-to-date. I think I’ll be writing some shorter posts and I’d like to say “more often”, but we’ll just have to see about that. Anyways…

Thanks to Manfred Stienstra who has so kindly offered me to use his styling to base mine on, because really it’s just not my thing. And Webby so I can create posts locally, with my favorite text editor, and store revisions in git; welcome to superalloy.nl version 2 and hope to see you around!