Integration of the testing library Jasmine

Registered by Maxime Vidori

Currently, we use qUnit as the unit test framework for the client side, with the integration of AngularJS, it seems to be interesting to improve the quality of our testing tools. Jasmine could be a great idea, it could be run standalone through a browser.
Jasmine brings some interesting features which could be really useful

Here are the features we do not have with qUnit:
  - it is possible to create ours own matcher:
  - it is possible to check the call of functions with the spies features
  - it is also possible to mock function with these spies, this feature may be the most important.
  - the reporter provide a readable interfaces for our tests, which allow the developer to see which functionality is broken.

Last but not least, AngularJS documentation provides a lot of testing examples based on Jasmine. This will be useful because we do not need any third party documentation, we can directly start the development of tests.

qUnit test in Horizon are not so important at this time and we could easily change for the Jasmine testing suite, I have already rewrote a lot of tests:

It is really easy to rewrote qUnit test into Jasmine one, the main features are closely the same. The goal is to replace completely qUnit.

Blueprint information

Matthias Runge
Maxime Vidori
Maxime Vidori
Series goal:
Accepted for icehouse
Milestone target:
milestone icon 2014.1
Started by
David Lyle
Completed by
David Lyle

Related branches



rdopieralski, 2013-12-03: Consider using a dedicated tool for spies and mocks like, instead of switching testing frameworks just for that.

mvidori, 2013-12-03: So we add another library just to patch qUnit, I am currently writing the JSHINT checker with Jasmine. If we choose Jasmine there will only be one framework instead of qUnit + sinonjs + qHint. With this developers have to check on the documentation of multiple libraries. Going to Jasmine from qUnit is not really hard. We do not have a lot of qUnit test, if all the architecture was dependent of this, I will be agreed that patching qUnit could be an acceptable issue.

rdopieralski, 2013-12-04: It's not about patching, it's about using the right tool for the job. If we don't like sinonjs or jshint, we can easily replace them with jsmock, jqmock, jslint, or whatever library turns to be best for the particular task. With a monolithic framework like Jasmine we are locked. Also, it's a one way ticket. While as you say, understanding and rewriting the qUnit tests is simple, getting rid of Jasmine, if we ever decide to do it, will be nigh impossible -- not only because we will have more tests and because the rewritten tests are longer, but mainly because they are almost impossible to read with that wonky syntax.

mvidori 2013-12-04: After reflexion, agreed with your point on the monolithic framework. The two solutions are acceptable, I think it will end on a matter of preferences. I do not really find the syntax disturbing, and I like the possibility to make nested tests on functionalities. Maybe a pros and cons table for each library could be interesting. I am just afraid of the jquery effect, a bunch of libraries for just one or two functionalities and no flexibility at all. I found Jasmine really customizable, in term of tests or messages.

Gerrit topic:,topic:bp/jasmine-integration,n,z

Addressed by:
    Add jasmine testing and helpers

Gerrit topic:,topic:jasmine-jshint,n,z

Gerrit topic:,topic:jasmine-rebase,n,z

[david-lyle 2014-01-21] jshint issues, plus lots of unmerged items. Moving to i-3

Addressed by:
    Replace horizon.utils with an angular one

Addressed by:
    Replace horizon.conf with an angular one

Gerrit topic:,topic:horizon-angular,n,z

Gerrit topic:,topic:bp/horizon-angular,n,z


Work Items

This blueprint contains Public information 
Everyone can see this information.


No subscribers.