I have been using jasmine and today I thought I would try jasmine-node. Some of the passing tests for jasmine fail in jasmine-node. Specifically, toBeLessThanOrEqual is not a function in jasmine-node. Is jasmine-node something that should be avoided?
The difference is the version of jasmine that is being used. With jasmine-node they use version 1.3.1 currently, while jasmine itself is much further along (currently at version 3.2). Since jasmine has had a couple of major version changes, there are breaking changes between them which explains why your tests that use jasmine 2.x or 3.x might not work with jasmine-node because the syntax is different.
Until jasmine-node updates to use a newer version of jasmine you would be stuck with the jasmine 1.x syntax, which isn't great.
Note that if you want to use istanbul for code coverage you'd also have to force it to used the same jasmine version that your tests are written with.
While jasmine-node can be convenient, I prefer to use the latest jasmine syntax so can't use it as it is.
Related
Now when Xunit 2.0 is release what is the possibility to run setup/tear down code before and after ALL tests are run?
It was not possible in Xunit 1 but according to this xUnit.net - run code once before and after ALL tests there were plans to support that behavior in 2.0.
It seems like in your case, Collection Fixtures could be helpful. You can find an example in xUnit documentation. In this example, a constructor and a Dispose method of the DatabaseFixture class are places where you can write setup / tear down code. Create a base class for your tests and use this collection fixture for it.
Here is the AssemblyFixture example published by xUnit, which shows how you can get assembly-level setup and cleanup: https://github.com/xunit/samples.xunit/tree/master/AssemblyFixtureExample
We have a TeamCity CI server that needs to be able to execute Jasmine 1.3 and Jasmine 2.0 tests (at different times, on different jobs). It is using the TeamCity Karma integration. My research so far is inconclusive, but it seems like Karma can only have one version of the Jasmine plugin at a time, so it's an either-or proposition. Another way to attack it would be to have two separate installs of Karma on the TeamCity server, but I'm a newbie at both TeamCity and Node, and not sure how this would work out. Any suggestions?
Thanks!
Karma looks for the karma-jasmine plugin in the local node_modules folder. The quickest way to switch versions is to simply replace the karma-jasmine folder with the version you want (automated or otherwise) before running your tests, but this has the potential to get messy.
Different installs of Karma is likely the cleaner way. There isn't any issue with having 2 (or as many as you like) local installs of Karma, since they all live under a node_modules folder. In an example directory structure like this, the Karma installation under 1.3 won't know anything about the Karma installation under 2.0.
/tests/
/1.3/
/node_modules/
/karma/
/karma-jasmine/
/2.0/
/node_modules/
/karma/
/karma-jasmine/
karma-cli, the module that lets you run karma in a command window from anywhere, however, is one that is installed globally and so has one installation.
If you ran karma start while in the 1.3 folder, karma-cli will execute the Karma under 1.3, which in turn will load the karma-jasmine under 1.3. The same applies when in the 2.0 folder. This gives you the option of maintaining versioned test dependencies.
In xunit reporter of mocha, it generates the report for attributes tests, failures, skipped, error. but i want for mocha's pending, dropped and blocked reports also. is these reports are generated using xunit? can we customize the xunit reporter to generate the report which has
pending
dropped
blocked
test cases report. please help me to find solution for this.
Looks like this is a known issue and pending tests have been added to the xunit reporter.
First are you using the latest version of mocha?
https://github.com/visionmedia/mocha/pull/1051/files that pull request has been merged into the latest version of mocha and should including pending requests in xunit?
You can always fork mocha and edit lib/reporters/xunit.js and add
runner.on('dropped', function(test){
tests.push(test);
});
runner.on('blocked', function(test){
tests.push(test);
});
Or instead of forking mocha. Copy Xunit and make a custom mocha reporter. You can use https://github.com/startswithaj/mocha-spec-cov as a template.
Could someone help by defining the relation between the following: Selenium, Webdriver and most importantly test-unit.
Thanks!
There is no relationship between Selenium and Test-Unit.
Selenium is the overall project which combines RC, WebDriver and Grid.
WebDriver is the newest and more stable piece in the project, allowing you automate a browser using much more stable so-called 'native events'.
TestUnit is simply a unit testing tool for Ruby. You write some tests using Ruby, run it using TestUnit, it verifies if your test passes or fails. You can use this to write Selenium tests.
This is mostly mentioned on the Selenium site:
http://seleniumhq.org/docs/03_webdriver.html
Can Chutzpah run qunit tests from a url? I need a lot of server-side injected markup and json data in my qunit tests, so I like to run the test suite within my visual studio project on localhost instead of mocking tons of test data in my test.js files.
As of version 2.4 Chutzpah now supports running against a remote url. See the documentation here.
Maybe it helps to share our testing strategy.
We use chutzpah for javascript unit tests. No dependency on a running server. The tests run very quickly as part of the build. (But we are not testing generated javascript code which is your scenario).
We test against running server by writing tests in JavaScript and running them with PhantonJS. See my answer for an example of one of our tests: automated functional web GUI testing frameworks (asp.net)
If you don't like writing the tests in Javascript like this (it is not as nice as using a unit testing framework - like qUnit or jasmine) you could checked out CasperJS.