Mocha runs independently from the assertion library, so you can choose which assertion format works best for you.
Mocha most often is run in combination with assertion library Chai.
No need to write tricky statements for Async testing. Mocha gives you a "Done" callback. Place this "Done" parameter in your callback function, that'll let Mocha know that you've written an asynchronous function. It's that dead simple.
The Mocha test framework itself runs on NodeJS, hence it makes everything related to it extremely simple. With Mocha's simple syntax and speed, testing your node.js app just got a whole lot easier.
Mocha has multiple test reporters built in and you can create your own as well. The test reporters have full color and makes it easy to see if your tests fail or not.
Aside from the numerous benefits with generators in your application, You can now also integrate generators into your test suite. By using mocha, all you have to do is enable support for generators.
Code readability is an important factor, if the application development involves multiple teams; if the testing team is unable to read your test cases then they won't be able to test it. Jasmine resolves this issue by providing developers with an extremely simple and "human-friendly" syntax.
If you have some test cases that do not involve testing of DOM elements or events, those are exactly the ones where you want to use Jasmine. It'll provide smooth, simple and easy DOM-less testing of those test cases.
There are times where you don't want to open up a browser for screencaps, that is where CasperJS comes to use, it can render the page using its own rendering engine and take and save a screenshot for you, all via the commandline
Can execute arbitrary javascript or load external JS into the page being tested. This feature is possible due to the presence of a rendering engine, and helps you see the effects of any client side scripting during your tests.
QtWebKit is the rendering engine used by CasperJS. Keep in mind this is NOT the same rendering engine as Chrome; hence, if you want to be 100% sure of the results, you must run a Webkit browser (such as Chrome) yourself.
Do you prefer other test frameworks such as Mocha, Jasmine, qUnit or any other framework? Well you're in luck as Karma can be easiliy be extended to wrap around ANY framework of your choice.
Karma eases out the UI testing process as you can test your code on all your devices let it be smartphones, tablets or your very own desktop. If you don't want all of that, you always have the option of headless testing using a PhantomJS instance.
Being able to test your code directly via your testing tool is a breeze! You don't need to download a fancy tool to see how your app looks in a number of different browsers, now that Karma would do the job for you.
Currently Karma doesn't support testing of apps built on NodeJS. So if you have a node app, you don't want to use Karma, Mocha or Jasmine can do the job for you.
Do most of your code using Eclipse, well, you're in bad luck. Karma doesn't have an eclipse plugin, though if you are a real die hard eclipse fan, you can see this little hack to be able to run Karma from inside Eclipse Link
(Time of writing: July 2014)
In cases where you want (I know your test cases must be atomic) where you really really want your test cases to run in a specific order, maybe if the current one rely on those of previous case, you can use Qunit by setting QUnit.config.reorder = false and your test cases will run in the order you've provided.
All frontend developers already know the ease that jQuery framework has brought to their lives, in handling DOM events and accessing elements. Since Qunit was built as a part of jquery (is even used by jQuery itself for unit testing) hence it makes testing of DOM elements a lot easier.
Seriously! All you have to do is include the Qunit library from the CDN, then create your Testcases js file, and RUN IT! . Your outputs would be displayed in a pretty little format in your browser.
Qunit, expects us to call the start() function before the Async function itself, and stop() after it stops. This can be a problem when you have no way of knowing, when your function will start or stop (your testing a number of dependent functions)
No need to comment out your entire test case, now that you have Buster, which supports deferring a test so it doesn't actually run, but you get notified that there’s a deferred tests every time you run your test suite.
Have your test cases written in another framework, want to use BusterJS to run the tests, then you're in luck. BusterJS can be easily wrapped around other test frameworks. If you need to know how to do it, here's a link that showing just that.
Working on a NodeJS app? BusterJS can help you Unit test it. This pretty much works just like browser tests, but you need to require Buster.JS in your tests.
Don't have time to go through the lengthy process of opening up your browsers? BusterJS gives you the option of performing Headless tests. These are powered by PhantomJS; hence all your testing is done within the command line.
Do you prefer running your test cases from inside your IDE? well BusterJS will make that a lot difficult for you if not impossible. You'll have to run Buster using the good old way of spawning up a new terminal for running the tests.
Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to Safari