autotest POC
Steven Parkes
Jasmine (Javascript BDD framework) specs under autotest.
env.js is an implementation of the browser environment in (mostly)
pure javascript. It's traditionally run on Rhino, the Mozilla Java
javascript interpreter, but now has preliminary support for
Spidermonkey/Tracemonkey, the C/C++ interpreter that's in Firefox.
(Spidermonkey/Tracemonkey support comes via the Johnson gem, which
integrates Ruby and Spidermonkey/Tracemonkey).
Screen shot at http://www.scrnshots.com/users/smparkes/screenshots/205913
.
If you're interested in trying it, you need the latest smparkes.envjs
gem (has to be installed as a gem, the way autotest works ... at least
so far). You need my lightly-tweaked version of Jasmine: git://github.com/smparkes/jasmine.git
. I've only started playing with Jasmine. The screen shot is actually
a run of the Jasmine specs. The changes are neither terribly dirty nor
terribly clean ... I'd like to work on a better integration with
Jasmine ...
You need to put "require 'autotest/envjs'" in your ~/.autotest. You
probably want to put something like "begin .... ; rescue Exception =>
e; end" around it so it doesn't kill autotest when you don't have it
installed. Hmm ... guess we could have a different command instead.
autojas?
In theory, that's about it. Just run autotest.
It will run JS tests if it looks like a Jasmine directory. If you have
both rspec and Jasmine specs (and/or test unit/qunit tests) in the
same hierarchy, I think you're kinda hosed; I don't think autotest can
handle that. I'm thinking of looking more into something like watchr.
I tend to write in multiple languages, so in this case, might need
something a bit less opinionated, where it runs all my tests in all my
languages at the same time.
Most of the changes to Jasmine are, more or less, factoring. env.js
can actually load the runner.html, but, right now, that just generates
results in a page, so no results at the command line. The Jasmine
specs don't actually need anything in the DOM, so I just use the
default page, about:blank. The tests can open other windows and load
docs into them if they want. Or load from an html file. I'm not sure
what the needs are going to be ... my early stuff/motivation has been
non-UI related JS.
You can still open the the HTML in the browser fine. I haven't tried/
don't really understand the ruby server stuff.
I'm kind of curious if this is of interest to anyone else ...
Rajan Agaskar
There's definitely a lot of people interested in this sort of thing, as it can be super-suitable for projects where you want to run a quick javascript check without having to crack open a browser. We'd be interested in hearing about what features in jasmine would help you build out this project -- we'd love to make jasmine useful for as many applications and people as possible!
Steven Parkes
On Oct 29, 2009, at Oct 29,7:16 PM , Rajan Agaskar wrote:
> We'd be interested in hearing about what features in jasmine would
> help you build out this project -- we'd love to make jasmine useful
> for as many applications and people as possible!
I'm sure I'll find stuff as I port over my Screw.Unit tests ... but I
suspect it'll take a while before I have an idea of what kind of
testing infrastructure pieces I, personally, want. I know I want
things like browser-less testing, both at the command line and via CI:
I'm looking at that now, figuring out how not to require custom html
fixtures for every test, providing a reporter that a CI system can
read, etc.
But if others want to start using it, I'm happy to help along that
path as well. In my repo, there are a few light changes made to make
the Jaz specs work with env.js, but unless other people want to start
using it, there's no hurry to push them upstream. There are slightly
bigger issues around fixtures/workflow which are less obvious the best
approach out of many possibilities, so if people want to explore
those ...
Steven Parkes
On Oct 29, 2009, at Oct 29,4:53 PM , Steven Parkes wrote:
> If you're interested in trying it, you need ...
Packaged as the smparkes.jazrb gem now, which comes with my version of
Jasmine and the install will (should) pull in all the other
dependencies.
Then, from the root of a project, like the jasmine root directory
(i.e., the parent of the spec directory), jazrb <specfile[s]>, e.g.,
jazrb spec/suites/EnvSpec.js, or simply "autojaz" to have it run all
the specs repeatedly.
The Jasmine structure is non-rspec-rails-like in that the sources are
in src instead of lib and the specs are one level deeper than the
sources, i.e., in suites. Latter is harder to adapt to than the former
for autotest. Means autotest can't figure out which sources match
which specs and so can't focus on failing specs. But that's not a big
deal, at least for now; the specs run sub-second.
Cheers.
Steven Parkes
to using (my own modified version of) watchr. It's evented (via
Eventmachine), faster, and is easier to teach about inter-file
relationships than autotest was.
I've put some examples in the jazrb repo (http://github.com/smparkes/jazrb
). It can run both XHTML and JS specs and knows how to link the two.
One thing I added was a JUnit-ish XML reporter, so that jazrb can
combine results from multiple HTML files, since these can't be
combined in JavaScript since they execute in their own environments. I
figure it'll be useful in CI too.
cheers