I am wondering what is the easiest way to do the JavaScript Unit testing as part of Rails 3.1 application.
I like Jasmine a lot and it works pretty well (although some tricks are required for it to pick up .coffee files).
The only problem I have with Jasmine is that it runs all the tests examples inside one huge page which is very problematic as it requires loading ALL of the scripts.
The thing I really want is Jasmine + multiple test suites in multiple files (so that it generates multiple html files including spec files).
In addition to that, I want to run tests (hopefully easily) in the browsers, headless or inside a JS engine (when possible).
Any recommendations?
Teaspoon does pretty much what you're looking for.
I wrote most of it, and it's based on my experience with writing javascript specs and using Rails 3.1 / coffeescript. Your question includes some of the very things that made me want to contribute it in the first place.
EDIT:
To clarify, Teaspoon supports defining multiple suites, has a rake task, supports using Selenium Webdriver or PhantomJS as drivers, Jasmine, Mocha, or QUnit test frameworks, allows running from the command line (eg. bundle exec teaspoon spec/javascripts/my_spec.coffee), and several other nice to haves.
Where i work, we wanted to find a solution to cover pretty much what you are mentioning.
We examined the following frameworks:
teaspoon
konacha
karma
bunyip
jasmine-rails
We finally picked teaspoon.
It required minimal setup and it was easy to integrate with our CI.
It provides suites, asset pipeline support (so that you can test .coffee without hacks) and it can run in RAILS_ENV=test
You might want to try the evergreen (https://github.com/jnicklas/evergreen). It allows you to write testcases with jasmine and run your tests in the browsers, headless or inside a JS engine.
You can found the usage of this gem on the readme section https://github.com/jnicklas/evergreen#readme
Unfortunately, evergreen doesn't play well with new rails 3.1 feature yet (at the time this answer is made). So I try to create some monkey patch to get it play well.
# config/evergreen.rb
unless defined?(CONFIG_EVERGREEN_LOADED)
CONFIG_EVERGREEN_LOADED = true
require ::File.expand_path('../environment', __FILE__)
unless "".respond_to?(:each) # this monkey patch make the old capybara play well with ruby 1.9.2
String.class_eval do
def each &block
self.lines &block
end
end
end
module Evergreen
class << self
def application_with_additions(suite)
app = application_without_additions(suite)
app.map "/assets" do
assets = Rails.application.config.assets
if assets.enabled
require 'sprockets'
sprockets = Sprockets::Environment.new(suite.root)
sprockets.static_root = File.join(suite.root, 'public', assets.prefix)
sprockets.paths.concat assets.paths
sprockets.js_compressor = nil
run sprockets
end
end
app
end
alias_method :application_without_additions, :application
alias_method :application, :application_with_additions
end
end
As of now, I haven't found a reasonable answer to this. But the issue #24 of jasminerice is probably the closes to the answer if it will be implemented
Perhaps try jasmine-headless-webkit. This offers the capability to run your Jasmine specs within a headless WebKit browser.
Related
I'm trying to get into Grunt, which I am new to, but I do not understand its utility.
I understand that it is a taskrunner. I understand that it can be used to do things like bundle, uglify, jshint, minify, etc etc etc, anything that can be turned into a scripted task.
But I don't see what advantage this gives. Nearly all of these can be run from the command line anyway, which is to say you could just combine them using a simple shell script. It seems to me that setting up grunt + gruntfiles and writing tasks is more work than writing a shell script, rather than less.
What am I missing about this?
Grunt is basically a build / task manager written on top of NodeJS. I would call it the NodeJS stack equivalent of ANT for Java. Here are some common scenarios you would want to use grunt under:
You have a project with javascript files requiring minification, and generally generating a front end build seperately (in case you're using say JAVA for your backend). (grunt-contrib-uglify)
When you save code on your machine during development, you want the browser to reload your page automatically (might seem like a small thing, but believe me this has saved me lots of time). (Live reload)
When a developer saves code on his machine, he wants a comprehensive list of JS errors / general best practice violations to be shown. (grunt-contrib-jshint)
You have a project with SASS/ LESS files which need to be compiled to CSS files on the developers machine during development, For example whenever he saves a SASS file, you want it to be compiled to a CSS file automatically, for inclusion in your page. (grunt-contrib-sass)
You have a team of front end developers who're working on the UI, and a team of backend developers working on the backend, you want the front end devs to use the backend REST API's without having to compile & deploy code everytime on their own machines. In case you were wondering, this isn't possible with a typical web server setup because XHR isn't allowed to be cross-domain by browser. Grunt can setup a proxy for you redirecting XHR requests on your own system within the grunt connect server to another system! (grunt-contrib-proxy, grunt-contrib-connect)
I do not think your shell script can do ALL of these. To summarize, yes, setting up a Gruntfile.js is tedious for someone who has had little exposure to javascript / is new to nodeJS, I went through the same pains as a learner, but Grunt is an amazing piece of software. DO invest the time to setup a proper Gruntfile.js for your front end project, and you'll thank god for making your life a lot easier :)
The Advantage vs shell script:
If you write shell script for every one of these tasks, it is tedious to maintain and then customize for every one of your needs. Gruntfile.js is actually pretty easy. there is a config that you init it with, specifying what tasks you want to perform, the sources and targets for each.
The integration with project seed generators on Yeoman, Gulp is another major factor to consider. Yeoman and Gulp come with Gruntfile.js' with intelligent defaults. For someone who is the sole UI contributor on his team, this is priceless to me!
For someone who is working on frontend technologies, if you have more than one person working with you, its rather easy for them to get to know Grunt, which is already well documented with a lot of answers on SO, than to get to know your shell scripts. This might be a factor in large teams.
The numerous plugins for Grunt extend base functionality. Unless your shell script is VERY popular, and VERY modular, I dont see plugins being built for it. This also extends to inclusion of new front end technologies in your project. Say, if you want to use typescript in your project tomorrow, your shell script will need to incorporate this and account for it with your own effort. With Grunt, its just as simple as "npm install " and adding a config.
Even though I agree with most advantages pointed in Accepted Answer, I still have to consider the disadvantages that are highlighted by Keith Cirkel in Why we should stop using Grunt & Gulp
Thus, some advantages are rebut by Grunt overheads and at least you should consider all this in your final decision of using Grunt, or not.
I want to ask if it is possible (and generally a good idea) to use npm to handle front-end dependencies (Backbone, jQuery).
I have found that Backbone, jQuery and so on are all available through npm but I would have to set another extraction point (the default is node_modules) or symlink or something else...
Has somebody done this before?
Is it possible?
What do I have to change in package.json?
+1 for using Browserify. We use it here at diy.org and love it. The best introduction and reasoning behind Browserify can be found in the Browserify Handbook. Topics like CommonJS & AMD solutions, build pipelines and testing are covered there.
The main reason Browserify works so well is it transparently works w/ NPM. As long as a module can be required it can be Browserified (though not all modules are made to work in the browser).
Basics:
npm install jquery-browserify
main.js
var $ = require('jquery-browserify');
$("img[attr$='png']").hide();
Then run:
browserify main.js > bundle.js
Then include bundle.js in your HTML doc and the code in main.js will execute.
Short answer: sort of.
It is largely up to the module author to support this, but it isn't common. Socket.io is an example of such a supporting module, as demonstrated on their landing page. There are other solutions however. These are the two I actually know anything about:
http://ender.no.de/ - Ender JS, self-described NPM analogue for client modules. A bit too involved for my tastes.
https://github.com/substack/node-browserify - Browserify, a utility that will walk your dependencies and allow you to output a single script by emulating the node.js module pattern. You can use a jake|cake|rake|make build script to spit out your application.js, and even automate it if you want to get fancy. I used this briefly, but decided it was a bit clunky, and became annoying to debug. Also, not all dual-environment npm modules like to be run through browserify.
Personally, I am currently opting for using RequireJS ( http://requirejs.org/ ) and manually managing my modules, similar to how Mozilla does with their BrowserQuest sample application ( https://github.com/mozilla/BrowserQuest ). Note that this comes with the challenge of having to potentially shim modules like backbone or underscore which removed support for AMD style module loaders. You can find an example of what is involved in shimming here: http://tbranyen.com/post/amdrequirejs-shim-plugin-for-loading-incompatible-javascript
Really it seems like it is going to hurt no matter what, which is why native module support is such a hot topic.
Our team maintains a tool called Lineman for building front-end projects. The tool is node-based, so a project relies on a lot of npm modules that operate server-side to build your assets, but out-of-the-box it expects to find your client-side dependencies in copied and committed to vendor/js.
However, a bunch of folks (myself included) have tried integrating with browserify, and we've run into a lot of complexity and problems, ranging from (a) npm modules being maintained by a third party which are either out of date or add unwanted changes, to (b) actual libraries that start failing when loaded traditionally whenever a top-level function named require is even defined, due to AMD/Require.js baggage.
My short-term recommendation is to hold off and stick with good ol' fashioned script concatenation until the dust settles. Until you have problems big enough or complex enough to warrant it, I suspect you'll spend more time debugging and remediating your build than you otherwise would. And I think most of us agree the best use of your time is focusing on your application code, not its build tools.
You might want to take a look at http://jspm.io/ which is a browser package manager. Has nice ES6 support too.
I personally use webmake for my small projects. It is an alternative to browserify in the way it brings npm dependencies into your browser, and it's apparently lighter.
I didn't have the opportunity to compare in details browserify and webmake, but I noticed webmake doesn't work well with modules internally using global variables such as socket.io (which is full of bloat anyway IMO).
I would be cautious about RequireJS, which has been recommended above. Because it is an AMD loader, your browser will load your JS files asynchronously. It will induces more exchanges between your client and server and may degrade the UX of people browsing from mobile networks / under bad WiFi. Moreover, if you succeed to keep your JS code simple and tiny, asynchronous loading is absolutely not needed !
I'm looking for the easiest possible Javascript unit-testing system for Rails 3.1 that is specifically capable of working with the asset pipeline out of the box.
I've tried various incarnations of the jasmine gem, including jasmine-rice, headless-jasmine-webkit. Jasmine gem does not appear to work with rails 3.1 out of the box, requiring tweaking of various config files. Jasmine-rice and headless-jasmine-webkit both have complicated dependencies and require more tweaking of the config file.
Any suggestions? Ideally I would need to include HTML/HAML fixtures, and be headless, but at this point I would be happy with anything that allows me to test my javascript with minimal configuration.
Jasmine is the best solution. We're using this to test all our JS code. It works beautifully with CoffeeScript as well.
But don't install the version of RubyGems.org (it's not been updated in a while), just get the latest from github, e.g. add to your Gemfile:
group :test do
gem 'jasmine', :git => 'https://github.com/pivotal/jasmine-gem.git'
end
Then you can run rake jasmine and go to http://localhost:8888 to run your tests. Headless webkit also works.
I was looking for something that would allow me to unit and functional test my javascript within MS Test in visual studio. Took me forever but I found WatiN. What WatiN will do is open internet explorer and run a web page. If you run your IDE as an administrator you can even open local HTML files.
I am currently using it with Visual Studio to run functional and unit tests on all my javascript. I think that so far this is the best solution out of the box for running javascript functional tests from your IDE. For my unit tests I used YUI test, but since you are opening a browser and running javascript within the browser you can use any javascript test framework you want (like qUnit).
I've been using QUnit, a simple yet effective Unit Testing library built on jQuery:
http://docs.jquery.com/QUnit
Hopefully late is better than never... I just wrote a small library that should solve your problem:
https://github.com/proxv/qlive-rails
It injects qunit and your qunit tests into live server responses. It also lets you set state server-side in advance of the tests (like logging in a user and setting content for the page) to reduce client-side mocking.
If you are using rspec, there's also an add-on that will run the qunit tests headlessly along with your other rspec examples.
I am just trying to get my head round unit testing in Javascript and RequireJS. I am building a web-app and obviously only want to have tests run in development not production builds.
Questions:
Do you just test when you want to, or do you have JS tests running
on every page load when in development?
If tests are only on demand
then how do you trigger your tests to run? Query strings (eg.
?testing=true) or something like that?
I just need an idea of how people go about testing in development. I am using BackboneJS, RequireJS and jQuery on the front end with a NodeJS/ExpressJS server on the backend.
For a Backbone project at work we have a maven build process that runs our automated javascript tests through jsTestDriver, and we read the results with Sonar. I usually run the tests manually (with 'mvn test'), but I could easily tell maven every time I save a file, for example. I wrote a post that shows how to integrate QUnit, Requirejs, and code coverage with JSTD that is independent of Maven: js-test-driver+qunit+coverage+requirejs. It also contains links to a QUnitAdapter that is way more up-to-date and developed than the one on the jsTestDriver site. I'll update this post when I manage to write about how I got jsTestDriver working with Maven and Sonar. Hope it helps.
Grunt is a popular JS build tool. There's something called grunt-watch that can monitor certain files for change, and execute tasks accordingly. You could easily run unit tests with something like this on every save.
Usually end-to-end tests take longer, and we use the CI for that. I've seen a presentation on Meteor TDD that does end-to-end tests after every save though.
There are many end-to-end test frameworks, and they can run in a headless browser like phantom js using a build tool like grunt. Some frameworks open an actual browser to run the tests, but run via command line and report results using XML.
If you break out your components enough, the tests could have a small enough scope to run on each save.
For some core code I use JsUnit + Rhino on build server. For more complex bits (usually interface) I use selenium (it also runs on build server). I don't test anything on page load, I only use not-compressed versions of scripts.
I don't any solution for integration tests.
We have a rich web client. Our controllers and service facades are written in coffeescript (JavaScript) and jquery. In the past they would have been java.
To run our JavaScript jasmine tests from Jenkins/Hudson, we use java's junit and htmlunit to load a test oriented jsp page which includes the jasmine specs.
When the Htmlunit tries to run, it blows up trying to getPage() probably because of an XML parser class path which is extremely challenging to track down in our world.
We just want to be able to run our JavaScript tests from Jenkins and have it report failure if a JavaScript test does not pass. We are just using jsp and htmlunit in order to run JavaScript tests. Can we load the JavaScript tests and javascript code into a JavaScript engine with Jenkins as the thing that kicks it off? If so, how?
Sounds like you're in a Java environment. My jasmine-maven-plugin might be a good fit.
Jasmine Reporters would also be a solution. It has instructions for running headlessly via PhantomJS for example, and it can generate JUnit XML so Jenkins can understand the test results natively, graphing test count, duration, and failure over time.
Also, the "xvfb-run" wrapper often provided with xvfb is a great help here, so you can do "xvfb-run phantomjs.runner.sh ..." in a truly headless environment.
I've previously solved this problem by running the tests with a node.js plugin called jasmine-node
This solution of course requires node.js and a few node modules to properly run the jasmine tests. There is no real browser running the tests, but an emulated one using a module called jsdom, which basically creates a headless browser, and more specifically, a DOM, which the tests can interact with.
There's node modules for jQuery, underscore and propably other too, so these can be tested too. You can even skip the whole browser emulation if you'd rather run the tests in a browser, though I find it too cumbersome compared to automated Jenkins testing.
jasmine-node generates jUnit test reports, which Jenkins can interpret just fine.
I just realized there is some jenkins-jasmine-node plugin that might ease this process.
Grunt is your friend
use grunt http://gruntjs.com/
with grunt jasimine https://github.com/gruntjs/grunt-contrib-jasmine
with nodejs http://nodejs.org/
on jenkins using https://wiki.jenkins-ci.org/display/JENKINS/NodeJS+Plugin
got this setup and it's really nice, plus this gives you a place to start making your build server do other nice things such as deployment, unit testing, etc you know, other nice things
Can you use selenium? That would actually use a real browser then and get as close to the real environment as possible.