We released this version of the gem yesterday. Included are two key fixes:
These means that the old instructions for using Jasmine with Rails 3 are now obsolete. Feel free to nuke the Jasmine gem from your repo and use this new version.
UPDATE: We’ve released a new version of the Jasmine Gem and these steps are no longer required. Please see the announcement here
Bad news, everyone! At the moment, the released Jasmine gem is not yet Rails 3 compatible.
Good news, everyone! We now have a short term workaround while we deal with the work needed to work seamlessly with Rails 3.
The Jasmine gem is the easiest way to integrate Jasmine into your web project, including Rails. It adds auto discovery of source & spec files, a tiny Rack app for running them, and a Continuous Integration task (using Selenium) to run your tests on every check in. We use this gem on all of our Rails projects today.
It uses RSpec to gather results from JavaScript making them available at the command line or part of your build results. And RSpec 2, which is required for Rails 3, has changed its interface. So the Jasmine gem is broken with Rails 3. We know what we need to do to fix the this, but until then here’s the workaround.
This fix is only for Rails 3. If you project is not using Rails or does not require RSpec 2, then you can ignore this post.
We’re going to use Bundler to install the Jasmine gem from a local repo copy of a branched version of what’s on Github. Got it?
Once you’ve already created your Rails 3 project, here’s a script that does the right things to vendor the Jasmine gem:
What you see above:
vendor/gems directory if you don’t already have oneOnce this is done, you need to add this line to your Gemfile, likely in a test group (if you have one):
gem 'jasmine', :path => 'vendor/gems/jasmine'
Run a bundle install to get the Jasmine gem installed.
cd ../../..
bundle install
Now you can run the generator to make your Rails project a Jasmine project.
bundle exec jasmine init
Try running the example Jasmine specs:
rake jasmine
…and hit http://localhost:8888. You should see 5 specs pass.
Now you’ll need to edit jasmine.yml and point to your source, spec, and helper files. Delete the example files once you get your specs up and working.
Lastly, you need to check in the Jasmine gem source into your project so that other development machines and your CI box can run your Jasmine specs.
.git directories in vendor/gems/jasmine and vendor/gems/jasmine/jasmine.gitignore files in vendor/gems/jasmine and vendor/gems/jasmine/jasminevendor/gems/jasmine to your repo directly (git add vendor/gems/jasmine)That should do it.
UPDATE: There was an issue in the repo branch that has been fixed.
Using these instructions the first time, you should be fine.
If you’ve already run them, then you need to:
cd vendor/gems/jasmine git pull cd ../../.. bundle install
And then rake jasmine:ci should work fine.
Pivotal Labs and the Jasmine team are pleased to announce the 1.0 release of Jasmine, our JavaScript BDD framework.
This release is largely about stabilization. We’ve fixed some bugs, stabilized our API, and improved support for JRuby and Ruby 1.9. There are several deprecations (especially around asynchronous ‘waits’ blocks and some matchers) to go along with the fixes and features. See the release notes for full details.
This release is available in standalone and Ruby gem versions.
Our upcoming priorities include improving the documentation, properly supporting Rails 3 and RSpec 2 and a number of other environments, and looking at all of your pull requests and issue reports. Jasmine’s backlog lives in Pivotal Tracker.
Big thanks to the Jasmine community for the pull requests; the majority of changes between 0.11.1 and 1.0 are based on user-submitted patches.
See you on the mailing list and make sure to follow us on Twitter: @jasminebdd…
Ideally would be tied in with user/role system where each accounting entry would be tied to a user, but also reconciled against a master account.
Recommendations? Latest and greatest?
One suggestion was to look at the code that Wesabe open sourced code when they closed their doors.
This is likely because the project included a submodule that wasn’t configured correctly, fix this in under Rubymine’s version control preferences.
rescue_from ActiveRecord::RecordNotFound, :with => :render_record_not_found) with Cucumber by temporarily setting ActionController::Base.allow_rescue = true. This is usually set to false in features/support/env.rbJSON.pretty_generate hates Rails 3 Hashes
This should work in most modern browsers. Follow the Mozilla docs, NOT the various blog posts about this.
If you are overriding to_json in any of your Rails models you should read Jonathan Julian’s blog post which explains the purpose of as_json vs to_json.
Choice quote:
Enter ActiveSupport 2.3.3. Now the creation of the json is separate from therendering of the json. as_json is used to create the structure of the JSON as a Hash, and the rendering of that hash into a JSON string is left up to ActiveSupport::json.encode. You should never use to_json to create a representation, only to consume the representation.
as_json is also easier to test because it returns a Ruby Hash instead of a String.
Pivotal Labs has been at the forefront of agile development since it’s early days. We’ve taken what we’ve learned by applying agile concepts on a countless number of real world projects, and honed these skills into a very effective way to build software. Along the way, we also built a great project management and collaboration tool – Pivotal Tracker.
Not only does Tracker serve as a critical component of our own development process, it’s also relied on by thousands of teams out there in the world, from open source developers, to fast growing startups, and high profile, established companies.
It’s a great app, yet we have lots of ideas for how we’d like to improve it. Want to help us? If you’re a Ruby on Rails developer, enthusiastic about agile development, and want to help us to take Tracker to the next level, read on.
We’re currently looking for developers in the Denver/Boulder, Colorado area. Familiarity with Ruby on Rails is important, as are strong Javascript, CSS, and overall web UI skills. At Pivotal Labs, we pair and test drive 100% of the time, so any experience with pair-programming and/or test driven development would be a huge plus. We’re also big on aggressive refactoring, so be ready to roll up your sleeves.
If you’re interested in working with us, please send your current resume to tracker-jobs@pivotallabs.com, and tell us a little about yourself. Principals only, please.
Rails 3 is now beta and the core team is asking people to try it out and report issues back. We decided to do a small spike to get some experience with the upgrade process and see if we could help identify any problems. The application we worked on was our own Pivotal Pulse CI aggregation display (which you can see in action).
Here’s a quick overview of the steps we went through:
The first thing we had to do was install RVM. Our development machines are standardized on Ruby 1.8.6 — which we wanted to keep, of course — but Rails 3 requires Ruby 1.8.7. We installed patchlevel 174 after finding that higher patchlevels are not stable with RVM.
$ rvm install 1.8.7-p174
We also found it useful to set 1.8.7 as the default.
$ rvm use 1.8.7-p174 --default
That will also set the ruby that TextMate uses (but not RubyMine). If you don’t want to set 1.8.7 as the default, you can manually set the version of Ruby that TextMate uses by specifying the TM_RUBY shell variable. (Tips on how to manage Ruby VM preference in RubyMine appreciated.)
With Ruby 1.8.7 set up, it’s time to install Rails. You need to install from gems, but because it’s a pre-release gem, there are a few extra steps. Here’s what it took on our side:
$ gem install tzinfo builder memcache-client rack rack-test rack-mount erubis mail text-format thor bundler i18n
$ gem install rails --pre
$ gem install railties --pre
$ gem install rack-mount -v 0.4.7
The first line installs the Rails 3 dependencies that are not, themselves, pre-release gems. RubyGems 1.3.5 has a bug that it won’t install non-pre-release gem dependencies of a pre-release gem. This is fixed in 1.3.6, we hear, but that release has other problems. The second line installs the Rails 3 pre-release gem. The third line fixes a “can’t find executable rails” error, and the fourth line installs the right verison of rack-mount — the current version, 0.5.1, seems to break things.
At this point, you should test your installation by generating and running a new app.
$ rails fiddle
$ cd fiddle
$ rails server # => replaces ruby script/server
But what we’re really interested in is an upgrade. Step 1 is the rails_upgrade plugin. The Pulse app was managing gems using geminstaller instead of Rails config.gem feature, so we added our gems to the bundler Gemfile by hand instead of using the upgrader task.
An interesting change in Rails 3 is that config/environment.rb has faded into obscurity. Init code that was located within the initialize block should be moved into config/application.rb. Any other code should be moved into initializer files in the config/initializers/ directory. Be careful with scoping of globals; you may need to add some ::s to the front of your constants to get them to work right.
The app needed a few other minor tweaks to get running:
map.resource :login, :controller => "sessions" converted automatically to just resource :loginrails server failed because there was no tmp/pids directory; once we created it, it started right up.raw to get the output markup interpreted.<%= historical_status_list(project) %> # => <%= raw historical_status_list(project) %>We had a few dependencies that flat-out didn’t work; the most important of these were rspec and rspec-rails. The Pulse tests are all rspec, and while we were able to get them to run by installing Mutwin Kraus’ modified version of rspec-rails as a plugin, they didn’t come anywhere close to passing. This may be due to our use of foxy fixtures – calls such as projects(:project_name) failed, as did references to fixture names in the foreign key fields in fixture yaml files.
Also not working:
Once we finished all the tweaks, we ran rails server, and the application loaded and behaved normally (just not on the first attempt, heh). Pulse is a small enough project that we can say with at least some confidence that the app still works, even though the tests are red. It does feel a little dirty to check that code in though — even to a branch.
Our customers are asking for richer interfaces and user experiences. And so we – and by “we” I mean the Rails development community – are writing more and more JavaScript. We’ve gone from ignoring JS (using RJS server-side) to rendering JSON and writing our own jQuery plugins.
But in this transition some of us left our objects & design patterns on the server. Just because you’re writing a click handler in JavaScript doesn’t mean it couldn’t, or shouldn’t, be a method on an object.
If you have a long-lived page, its data are clamoring for object orientation. That data needs to be loaded, reloaded, and paginated via AJAX calls – why build that code (or that interface) more than once?
What about APIs that you’re accessing via AJAX? Wrapping an API in an object means you can more easily mock out the actual service in test and keep all the parameter logic separated from your data models. Or even more exciting, you can reuse your API code on the server (thanks for the timely example, Dion!).
JavaScript already has objects, but how do you organize your code in a more object-oriented way?
I’m a fan of a more Pseudo-classical approach to my JavaScript. (Sorry, Mr. Crockford, but I’m spending nearly all my time in Palm webOS these days and Mojo new‘s my objects). I’m not a fan of Prototype.js’s Class.create – $super is awkward, puts too much responsibility on the coder, the errors you get when you forget one are confounding, I don’t need to rename my constructor…the list is a bit longer, but you get the idea.
Instead we use JavaScript prototypes a lot like Ruby’s Classes – objects that implement common “class”-wide behavior. We setup an inheritance graph between child & parent prototypes – much like Google’s Closure. And we explicitly call functions on parent prototypes when we need “super”.
The result is a set of techniques that behaves enough like Classical inheritance for us to be productive. More importantly, we like it and the code we write with it – if there’s demand, I’ll write up an example.
Defining objects for purposes of encapsulation, abstraction and ease of testing (no matter the technique) is not only possible in JavaScript, they (surprise!) offer all the same benefits they do in other languages: less code that’s more robust and that you don’t mind extending & maintaining.
Why else is this important now? THE FUTURE.
Writing HTML5/RIA/MobileWeb applications in JavaScript is different than Rails/MVC web development. In order to make our code manageable we’ll need and want to crib from the object-oriented patterns of desktop client development.
But that’s another post.
RubyMine and gem bundler don’t seem to get along – RubyMine complains that bundled gems aren’t attached but these gems aren’t available when we try to attach them. Any ideas?
RubyMine uses your gem path so you’ll be able to attach to the gem if you add your gem bundler path to your ~/.gemrc file
There’s an option to disable this nagging alert in the preferences.
Is there a good Rails plugin skeleton/template out there?
Know of one? Let us know in the comments.
Don’t use sleep 1 or such in before blocks in rspec if you need to ensure a delay between two events. A before block is ran between all nested contexts so you’re probably incurring a larger penalty. Instead, you should stub Time.now.
One team implemented git commit hooks to facilitate communication – on rebase or merge new messages from a text file in the project root are displayed to alert other pairs to changes such as gem upgrades, noteworthy database changes, etc.