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.
Related
I am using Webpack to build a webapp that is designed for the browser.
After my build process I have two files: index.html and app.bundle.js
To my dismay I have found that the although the development Webpack configuration works the production configuration does not because of errors during minification.
I am looking for the most basic way to run a test that does the following:
Opens the index.html file (which contains <script defer="defer" src="app.bundle.js"> and sees if there are any errors when the script contained in app.bundle.js runs
That is it.
I need a full Browser environment (requestianimationframe, fetch, etc.)
I have tried JSDOM and I get Error: Uncaught [ReferenceError: fetch is not defined] which looks like it has a bunch of issues, and then there are a tremendous amount of overlapping libraries and tools like Phantom.js Zombie.js Pupeteer, headless-chrome etc. and I honestly can't figure out how to just open my app. I have tried to explore all of these tools but they are all complicated.
Ideally I wouldn't have to create a local webserver, but I'd be fine with that if this is what is required.
The 'best' way to do this IMHO, would be to have a full test environment that mirrors your production environment that you can deploy to and then run tests against, using a framework like WebdriverIO or Playwright. But that can be prohibitively expensive and requires a fair amount of devops work.
Your second best option is probably to configure a local webserver on whatever machine you run your tests on and spin up Selenium or Puppeteer tests there. Leveraging a framework like WebdriverIO or Playwright a basic sanity check test shouldn't take more than an hour or two to set up.
I am trying to run Mocha tests within the Meteor test framework for a certain subset of code in a Meteor project. In particular, this is an internal library that does not actually use any Meteor features, and the test just needs to read in a file, do some computations, and compare results (no server or database or anything). So in theory, this could be its own package with its own testing framework. However, I would still like to use the Meteor test framework if possible just so that I don't need to run two sets of tests. Also, it would be nice to avoid maintaining the dependencies associated with a second test framework. So I have one general and one specific question along these lines:
Which testing package (see http://guide.meteor.com/testing.html#mocha or recommend another) is most appropriate for running "plain" Mocha tests, i.e. most similar to just running mocha from the command line? It seems to be dispatch:mocha, but it "only runs server tests", which doesn't seem ideal. It would help to get some clarification on exactly what "only runs server tests" means and how dispatch:mocha differs from plain mocha.
I was able to get a test sort of working with dispatch:mocha, but there were two problems:
I had to put the test file in the server directory, even though it is shared client and server code.
In order to read test data from a file, I had to put the test data in the private directory and use Assets.getText(). I initially tried (and would prefer) to put the test data in the same directory as my test, but the test gets built in some kind of way that ignores my test data in that case (I can give more details if this is supposed to work).
Is there some way I can avoid the above?
I'm a big fan of the continuous testing setup offered by NCrunch in Visual Studio, and would love to have a similar setup with nodejs.
When writing JavaScript in node I use Sublime Text 2 as my editor, with tests written using Mocha.
I wondered if there was software (or a ST2 plugin) for achieving similar concurrent testing to that offered by NCrunch when writing .NET code?
After doing some digging around I've decided that the solution for the moment is:
Server-side: Mocha
mocha -w test
Using mocha's built-in watch functionality.
Client-side: Testacular
I'm now using testacular, which is truly awesome. It would be great it if had hooks for running the server-side watch progress in tandem, but not really a problem.
I haven't tried it myself yet but it looks promising: wallaby.js The description from the website has the following description
Wallaby.js is an intelligent test runner for JavaScript that
continuously runs your tests. It reports code coverage and other
results directly to your code editor immediately as you change your
code. Wallaby.js uses various tricks to run your tests as fast as
possible, such as dependency analysis to only execute tests affected
by your code changes and parallel test execution.
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.
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.