Django, now with JavaScript tests(docs.djangoproject.com)
docs.djangoproject.com
Django, now with JavaScript tests
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/javascript/
28 comments
You should check out my new integration testing framework:
http://hitchtest.com
It handles a lot of the boilerplate for running services like django, celery, postgres, etc. as well as getting selenium up and running with firefox so that you can simulate clicks and stuff and a mock SMTP server so that you can simulate sending emails.
http://hitchtest.com
It handles a lot of the boilerplate for running services like django, celery, postgres, etc. as well as getting selenium up and running with firefox so that you can simulate clicks and stuff and a mock SMTP server so that you can simulate sending emails.
Thanks! This looks pretty nice.
I like how you've added the option to 'time travel' and check for example if a reminder mail is being send correctly.
Glad you like it.
>I like how you've added the option to 'time travel' and check for example if a reminder mail is being send correctly.
Yes, those two things are a large part of why I wrote it.
I wanted a clean integration with libfaketime and I wanted to be able to create simple mock services that logged out JSON that the test could wait for with epoll, parse and use to verify that the event interaction occurred (e.g. email got received by SMTP gateway/API call was made).
>I like how you've added the option to 'time travel' and check for example if a reminder mail is being send correctly.
Yes, those two things are a large part of why I wrote it.
I wanted a clean integration with libfaketime and I wanted to be able to create simple mock services that logged out JSON that the test could wait for with epoll, parse and use to verify that the event interaction occurred (e.g. email got received by SMTP gateway/API call was made).
Cool thanks - I'll look at it!
Have you looked Selenium's Python integration? [1] If so, what issues prevent you from using it?
1. https://selenium-python.readthedocs.org/
1. https://selenium-python.readthedocs.org/
Splinter is based on that
We have started tests with PythonJS for testing this and, carefully, also for writing the actual JS. So far it works really well; PythonJS is very nicely done and after playing with it for a few hours (!) code looks and feels better than the corresponding JS.
https://github.com/rectangletangle/imjf-py
I wrote this Python client which facilitates basic JS integration testing.
I wrote this Python client which facilitates basic JS integration testing.
You can try bok-choy ( bok-choy.readthedocs.org ).
This is great news. Currently our js tests are run as part of Django's testing framework using Splinter (Selenium wrapper) to do browser automation. Those are hacked together using some partially documented class methods on top of pyvirtualdisplay and some X server packages so they can be run on a Linux server. Writing the tests themselves is a bit of a nightmare and involves writing pure js inside of Python docstrings and then injecting them into the virtual browser and inspecting the results. So yeah, looking forward to upgrading and using this.
Having read the article, it just looks like they run QUnit to test the JS bits of the admin and GIS contrib apps. It doesn't look like anything you couldn't have cobbled together before.
QUnit with no alternatives?
I guess the audience of the JS tests mostly consists of jQuery users, so it's probably not as strange as it seems to an outsider.
I wonder whether there are any reliable stats on test framework popularity in the wider JS community. The only numbers I've seen suggest that it's mostly Mocha and Jasmine.
I guess the audience of the JS tests mostly consists of jQuery users, so it's probably not as strange as it seems to an outsider.
I wonder whether there are any reliable stats on test framework popularity in the wider JS community. The only numbers I've seen suggest that it's mostly Mocha and Jasmine.
QUnit is used to test the Javascript that is shipped as part of Django. Any application specific tests can use any JS testing framework the developer desires.
That explains the choice, then. It's sensible to use whatever is already there as a default unless you plan to convert the existing tests.
This was addressed in the DEP: https://github.com/django/deps/blob/master/accepted/0003-jav...
For a bit of background, DEPs are a bit of an experiment at the moment to try and flesh out discussions for changes and improvements that might not have a clear cut answer.
For a bit of background, DEPs are a bit of an experiment at the moment to try and flesh out discussions for changes and improvements that might not have a clear cut answer.
I applaud them on this decision. I always found QUnit to be minimal, elegant and in similar taste to Python ecosystem.
Also EditorConfig and JSHint, good on them.
Also EditorConfig and JSHint, good on them.
I'm a big fan of http://unitjs.com/
My cursory internet sleuthing has revealed that Angular and React use Jasmine, whereas Ember and CoffeeScript use QUnit.
Haven't found an instance of Mocha. Most job postings I've seen indicate that Jasmine is the dominant test framework.
Haven't found an instance of Mocha. Most job postings I've seen indicate that Jasmine is the dominant test framework.
The official React repo actually used Jest, which is Facebook's own testing framework/test runner/Frankenstein's monster.
Basically an old 1.x version of Jasmine, bolted to a test runner, a JSDom environment, and a ton of mostly working automocking magic. It's glacially slow and kind of buggy, and in my experience most projects using React use Mocha, not Jest. And I haven't run across any using actual Jasmine (Jasmine and Jest are neither compatible nor interchangable).
As a general rule, I'd say node-based projects are heavily mocha based, whereas browser-based projects are much more mixed. CoffeeScript based projects seem especially likely to use Mocha over Jasmine; Angular (as you noted) has a strong preference for Jasmine due to their Protractor tool, etc. QUnit seems to be used by a lot of libraries and frameworks, but to have almost no usage among projects; I've never seen QUnit tests in the wild except in framework/library repos.
And as a final data point, note that on NPM, the main mocha package has almost 5 times the weekly downloads of the main jasmine package.
Basically an old 1.x version of Jasmine, bolted to a test runner, a JSDom environment, and a ton of mostly working automocking magic. It's glacially slow and kind of buggy, and in my experience most projects using React use Mocha, not Jest. And I haven't run across any using actual Jasmine (Jasmine and Jest are neither compatible nor interchangable).
As a general rule, I'd say node-based projects are heavily mocha based, whereas browser-based projects are much more mixed. CoffeeScript based projects seem especially likely to use Mocha over Jasmine; Angular (as you noted) has a strong preference for Jasmine due to their Protractor tool, etc. QUnit seems to be used by a lot of libraries and frameworks, but to have almost no usage among projects; I've never seen QUnit tests in the wild except in framework/library repos.
And as a final data point, note that on NPM, the main mocha package has almost 5 times the weekly downloads of the main jasmine package.
Jasmine is widespread but Mocha is pretty much the norm for modules on NPM. This is in part because Mocha is considerably easier to instrument.
Indeed, it's better in a bunch of ways! The one that finally got me to switch was that Jasmine didn't have an official CLI version for the longest time; it was browser-based and the CLIs were all third-party (and none of them very good). It includes one now, but it was too late.
We first adopted Jasmine for our internal JavaScript tests in ArangoDB (https://www.arangodb.com) to replace the ancient and inconvenient framework we were using before. It worked, kinda, but it was a mess. We still needed something to expose to developers wishing to test their own apps in the DB and doing that with Jasmine proved to be pretty much impossible.
It was extremely straightforward to integrate with Mocha, though. We just needed to stub out some of the node.js-specific code and provide a very small wrapper to provide our own module loader and reporting plugins. There is an active effort to split up Mocha into multiple modules in order to make it more portable, which would make the stubbing unnecessary, too.
It was extremely straightforward to integrate with Mocha, though. We just needed to stub out some of the node.js-specific code and provide a very small wrapper to provide our own module loader and reporting plugins. There is an active effort to split up Mocha into multiple modules in order to make it more portable, which would make the stubbing unnecessary, too.
Quite coincidentally ran across this survey from 2014 that shows Jasmine and Mocha are pretty much neck and neck.
https://s3.amazonaws.com/dailyjs/files/2014-survey-summary.p...
From TFA:
> Behind the scenes, compress.py is a front-end for Google’s Closure Compiler which is written in Java. However, the Closure Compiler library is not bundled with Django directly, so those wishing to contribute complete JavaScript patches will need to download and install the library independently. The Closure Compiler library requires Java 7 or higher.
Why Java? Why Clojure?
How did the core team of django come to the conclusion that Java should be apart of the stack?
> Behind the scenes, compress.py is a front-end for Google’s Closure Compiler which is written in Java. However, the Closure Compiler library is not bundled with Django directly, so those wishing to contribute complete JavaScript patches will need to download and install the library independently. The Closure Compiler library requires Java 7 or higher.
Why Java? Why Clojure?
How did the core team of django come to the conclusion that Java should be apart of the stack?
Has nothing to do with Java.
There's no stack.
They're simply chose the best Javascript compiler available.
Pretty simple, really
Pretty simple, really
> Why Clojure?
Not Clojure, the Lisp dialect. Closure is a JavaScript dialect invented by Google with some niceties added. They seem to be using their minifier.
If you are running Eclipse, you already have a Java runtime somewhere in your machine anyway.
Not Clojure, the Lisp dialect. Closure is a JavaScript dialect invented by Google with some niceties added. They seem to be using their minifier.
If you are running Eclipse, you already have a Java runtime somewhere in your machine anyway.
AFAIK there isn't a widely-used, solid JS compressor written in Python, so you're adding a dependency either way. You either need a Java runtime for the Closure Compiler, or you need Node to run uglify or similar.
I'm currently using pytest-splinter with phantomjs2, everything works quite well, but I had issues with simulating clicks (I'm still at an early stage of exploration, it could be my fault).
Any similar experiences?