662817 - Unit testing framework for Javascript

Status: RESOLVED WONTFIX

(Webtools Graveyard :: Elmo, defect, P3)

Description

[Peter Bengtsson [:peterbe]]

We need a framework for unit testing javascript. I personally favor using QUnit and to hook this up I suggest we look at using https://github.com/codysoyland/django-qunit to wire it up to django. 

The framework must be able to run without dependencies on the actual mysql database. I.e. all AJAX related calls needs to be mocked. It should be possible to run all javascript unit tests without the server running.

Comment 1

[Peter Bengtsson [:peterbe]]

Note to self: I should add a use of Mockjax into the sample tests
http://code.appendto.com/plugins/jquery-mockjax

Comment 2

[Peter Bengtsson [:peterbe]]

Note to self: Pull request for my fork of django-qunit here https://github.com/codysoyland/django-qunit/pull/3

Comment 3

[Peter Bengtsson [:peterbe]]

Attachment: Inserts basic framework for writing QUnit tests

Because I haven't had an response from the maintainer of django-qunit [1] I have instead set to track my fork [2] which allows for HTML fixtures. 

Once this is in, I can write up a little Wiki page for how to get started with writing tests. Especially the slightly more challenging AJAX async ones. 


[1] https://github.com/codysoyland/django-qunit
[2] https://github.com/peterbe/django-qunit

Comment 4

[Axel Hecht [:Pike]]

I did a few comments on the pull request, but I'd like to get Stephen to comment on the choice of django-qunit and its possible integration into automated testing infra on the QA side before looking at this too deeply.

Comment 5

[Peter Bengtsson [:peterbe]]

(In reply to comment #4)
> I did a few comments on the pull request, but I'd like to get Stephen to
> comment on the choice of django-qunit and its possible integration into
> automated testing infra on the QA side before looking at this too deeply.

That's excellent. Looking forward to that. 

I would just like to point out that QUnit, unittest and emacs/vim are tools we use to build. Not to QA.

Comment 6

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #4)
> I did a few comments on the pull request, but I'd like to get Stephen to
> comment on the choice of django-qunit and its possible integration into
> automated testing infra on the QA side before looking at this too deeply.

Yeah, right now, my team is largely Selenium-only; if you'd like more feedback on other automation tools, etc., the QA Automation Services team (David Burns, David Clarke, Geo Mealer, Dave Hunt, Henrik Skupin) can help.

Comment 7

[Axel Hecht [:Pike]]

David, any suggestions/comments from your side? The question is mostly on how we'd integrate testing of our js code into our jenkins jobs with the most synergies internally and externally.

Comment 8

[David Burns :automatedtester]

I really like QUnit or JSTestDriver for JavaScript tests. They work quite well with CI servers

Also the AMO team have https://github.com/kumar303/jstestnet which is a QUnit tool but allows your to run your tests in multiple browsers.

Comment 9

[Peter Bengtsson [:peterbe]]

So, QUnit is good. Shall we go ahead and use it as a testing framework?

Comment 10

[Axel Hecht [:Pike]]

Comment on attachment 546522 [details] [diff] [review]
Inserts basic framework for writing QUnit tests

I'll clear that review request to get a few questions answered:

Can we put the tests for apps into the apps, or do they need to be in the top-level static?
Is it a bug or a feature that the tests are served in non-debug, while qunit urls only work in debug?

The .#fixture.html file clearly shouldn't be in here, and I guess we shouldn't have dummy tests.

Comment 11

[Peter Bengtsson [:peterbe]]

We talked about this at length in one of the meetings. Our javascript code is not worthy of proper unit testing. There's basically no meat on its bones. If anything we decided we should run integration tests of the Javascript and this is best done using LiveServer and Selenium.