A few things from Ruby are nice in JS (the each method, for instance) but I’m with you on not re-creating a language when the existing tools do just fine.

I emailed Alan a couple times before I implemented any tests for Jazz with JSSpec, hoping there was a concise, non-kludgey-feeling way of using `before` and `before_all`, etc setup/teardown of data for test sets. He said that for the now I’d have to stick with globals and delete them in the `after` functions, which is what I’m doing for the time being. As long as you’re careful it’s not a big deal, but it doesn’t /feel/ right, I know.

I’d heard something about JSSpec2 but yeah, don’t feel the need to try it at this stage. I will be trying to get my existing tests to run in AIR and Titanium shortly, as we advertise those as supported platforms and I’d like to automated test more thoroughly.

Looked over the amok stuff. Pretty cool. Seems fairly similar to JSMock with diff language.

Sorry blog, I had nearly forgotten all about you!

Thanks for the feedback Nick. Yep I don’t know where I’d be without BDD, well actually I do know as testing is something I’ve learned about the hard way in the past. We had a project where we reverse engineered the Google Maps API and plugged it in to an open source mapping engine. That was a project where testing was extremely important as at that time the Google Maps API was changing so frequently, so we used every JavaScript testing product we could lay our hands on at one point or another.

Since writing the article above there have been some new developments, there’s been a new BDD framework released called ScrewUnit (http://github.com/nkallen/screw-unit/tree/master), looks quite cool but I really hate it when developers try making JavaScript look like Ruby, trying to recreate symbols and such, so I’ve stuck with JSSpec.

Also I’ve been in contact with Alan from JSSpec and he informed me JSSpec2 is at alpha stage, this new version has a HMTL, Rhino and Windows Script Host runners, so now it’s possible to start setting up a continuous integration process for your JavaScript projects, which I am extremely excited about. Unfortunately the current release only has an xUnit style DSL, but the BDD dsl is in the todo list. You can get it out of the JSSpec SVN on Google Code.

Also there’s a new mocking framework called (amok) which I wrote, I haven’t publicised it as I wrote it mainly for internal use, but it’s open source and available at Google Code (http://code.google.com/p/amok/).

Cheers,

Chris

I find BDD to be much more sensible than testing all the internals and things users of your code will never touch. I think of it as black box testing and feel it really makes for better stability without greatly affecting time to test. Adding a few JSSpec tests for a new feature (or something as yet untested) takes a few minutes – not much longer than simply verifying something works for myself in Firebug – but lasts for the life of the project.

It’s more a mindset change than anything else. Before doing BDD (this applies to all languages) I was testing internals unnecessarily and re-reading old tests was such a pain. With the more declarative nature of BDD test frameworks (like `value_of(X).should_be(Y)` in JSSpec) is immediately recognizable for what it is testing, and makes digging into the details that much easier.

The only thing that could improve the JSSpec experience would be if it could somehow be integrated in the deployment process automatically as an enforcement of rules. I’ve made a few deployments now where I had fixed bugs in component files of JazzRecord, but forgot to build the actual release file, which JSSpec tests against. If someone knows how to do this I’d greatly appreciate the tip!