-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for the information Jannis. I hadn't realized that project got to the point of a pull request.
Personally I prefer running unit tests without LiveServerTestCase. It seems like LiveServerTestCase should be used for functional tests (using selenium) and not unit tests. I had not anticipated taking up the task of creating a custom Python-based test harness for JavaScript tests. I am not necessarily opposed to this idea, but it seems like a complex solution to a simple problem. I'm more concerned with getting the JavaScript properly tested than I am with creating a Python-powered JavaScript test harness. I think that problem (if it is one) could be resolved later without much hassle in migration. I disagree with Marc's suggestion that being able to run both Python and JS tests at the same time "must be better". I see these tests as distinct from the Python tests. I am certainly biased from my past experience attempting to run JavaScript tests through Python and giving up in favor of the more common solution of using Node and PhantomJS. The great thing about JavaScript tests is that they just run in HTML files, so if JS unit tests are run through PhantomJS and Node initially they can be migrated to use a Selenium and Python wrapper later if desired. Also, regardless of the solution chosen, it should always be possible to manually run the tests with a web browser. Sorry for the gap in my reply time. I have been busy this week and haven't had time to put together a DEP yet. On 04/19/2014 04:50 AM, Jannis Leidel wrote: > Hi Trey, all, > > I know we shortly talked about that at PyCon but I forgot to mention > that a while ago we took a stab at that already. Sean Bleier was spear > heading it and I helped out here and there: > https://github.com/sebleier/django/compare/4f3ad28a9b4ffc3ae9866d14f242844d5720b3be...qunit > > Sadly we never finished it, even though it was supposed to be merged > together with the LiveServerTestCase. It was providing a "jstest" > management command that was just runserver in disguise with an > enforced URLconf with a few views to render JS test pages. > > The actual core part was a collector for JS test suites > (conventionally placed in <app>/tests/javascript). Each suite could > test any kind of local and remote files and used staticfiles for > serving them. > > I'm not suggesting to re-use this code but wanted to mention that > we've worked on it and found it pretty good (at the time). We just > lacked the time to finish it. Also, some parts are specific to QUnit > but others (like the suite collector) could be reused for other test > runners. > > All in all, I'm all for supporting some way for writing JS tests as > part of Django apps but would be a lot more careful about what > technique/tool to use given the fast paced changes in JS land. I admit > I don't have experience with Jasmine though so take my advise with a > grain of salt :) > > Cheers, > Jannis > > > On 16.04.14 23:57, Trey Hunner wrote: >> I saw a previous discussion about JavaScript testing in Django but >> it looks like there hasn't been any progress in a few years. > >> Some of my thoughts on this issue: > >> This would require choosing a JavaScript testing framework. There >> are many good ones out there. A popular one should probably used >> for easier community support. > >> Unit testing JavaScript (ideally) should not require running the >> Django server. > >> JavaScript tests will probably require introducing Node.js into >> the automated testing process. Tests can be run manually from the >> browser, but automated JavaScript tests tend to require Node.js and >> sometimes PhantomJS (for headless testing). > >> The JavaScript tests should be run as part of the CI testing >> process. If the tests are run standalone this should be easy to do >> using a single command (possibly requiring grunt or a similar task >> runner). > >> This seems like it would be a big change, but I think it could be >> done in small steps. Setting up the testing framework is the first >> big step. > >> What do others think about this issue? > >> -- Trey Hunner > >> -- You received this message because you are subscribed to the >> Google Groups "Django developers" group. To unsubscribe from this >> group and stop receiving emails from it, send an email to >> [email protected] >> <mailto:[email protected]>. To post to >> this group, send email to [email protected] >> <mailto:[email protected]>. Visit this group at >> http://groups.google.com/group/django-developers. To view this >> discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CACuWcAwHVJ7HfeWOui3pAT3nQJeABP_Vt5WQe1N5%2BvDs%2Bnt8GQ%40mail.gmail.com > > > <https://groups.google.com/d/msgid/django-developers/CACuWcAwHVJ7HfeWOui3pAT3nQJeABP_Vt5WQe1N5%2BvDs%2Bnt8GQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout. > - -- Trey Hunner http://treyhunner.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWMJ0AAoJEOpnfp/NreonPDUIAJZzgCu7YNWz2dLlndlmOQ4P lRIOSdQcVX4RDAEkZheaQRcymTdXA6GfpzHhQ46RZMW6V8RCuoIwCTAy+My3wEgO IbMNufIcUh7Kn8sLWxoD/sOCcBjhqTAtCQqfMywYMNtHfCSdUJ/lhUHyRc5CRHYC CmsXR3rsapc6SHcg0tVCsMQL2V63RLZi1+xAnlBv7CVVcUfSsrEh1k1hw22eFGvP 257Tjb+bl81K48QvFKZoH9vefRnbTKkX7sxxbPsWEC4/T2+Zb6MRU8qzmq+8fUEP blF3QXNrFudbhI1eAGOKPmmKRhuzHfz+Bx4fVf/JowQuG5cMlk8oLIYpyzmhA5M= =Fhuu -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5358C274.4080404%40treyhunner.com. For more options, visit https://groups.google.com/d/optout.
