

Django, now with JavaScript tests - rbanffy
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/javascript/

======
ecesena
I'm actually more interested in the opposite, i.e. writing python code that
tests a js (react) ui.

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?

~~~
crdoconnor
You should check out my new integration testing framework:

[http://hitchtest.com](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.

~~~
nichol4s
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.

~~~
crdoconnor
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).

------
epberry
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.

~~~
bjt
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.

------
pluma
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.

~~~
ihsw
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.

~~~
Lazare
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.

~~~
pluma
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.

~~~
exogen
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.

~~~
pluma
We first adopted Jasmine for our internal JavaScript tests in ArangoDB
([https://www.arangodb.com](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.

------
anon3_
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?

~~~
arthur_debert
Has nothing to do with Java. There's no stack. They're simply chose the best
Javascript compiler available.

Pretty simple, really

