

Ask HN: How do you test web UI/JavaScript? - smarterchild

We just set up QUnit, and it was kind of a difficult Google-fest to get working. On the UI side however, I haven't touched a UI framework since Selenium a while back.<p>What do you use to test UI/UX on the web?
======
jfaucett
To put it bluntly from my perspective, testing js is pretty much hell. Don't
get me wrong, it does depend on the context though. For example, if I'm
building a jQuery plugin or my own pure js libraries then qunit is in my
opinion the best solution and it does a great job - I'd recommend it :).

But once you start to have to test large applications where the server side
app and javascript are intertwined, you start running into lots of problems.
I'm just guessing but I think this is the case for most devs that really want
to test their javascript. Most arent building a library they're using one,
they're also probably not building one page apps that are pure javascript,
more like components that are getting integrated into larger (existing)
applications. And personally, I haven't been able to find a solution that
works well without tons of annoying headaches, that are often more trouble
than clicking through your app in various browsers and os's for a day. So if
anyone has found a solution i would love to hear about it PLEASE! :)

Right now you can try selenium (I personally don't like it, but wont go into
it here), then you can also try something like phantomjs (or another headless
browser), but this wont let you test IE at all, which usually defeats almost
the whole point. Also you're most likely going to run into problems dealing
with context, because your javascript is being inserted into the testing
browser inside the test suite context (long story but I've had problems here
too). Capybara has problems with testing async js, but you could try it. In
summary its just a pain, I wish someone had a solution too but I unfortunately
dont.

~~~
smarterchild
Do you do testing by hand now?

------
noginn
My team started off with QUnit but switched to Mocha a while back for unit
testing our JavaScript. The tests run in the browser or using Node.js (on the
build server).

We've dabbled with BusterJS as an alternative when needing to run the tests in
multiple browsers/devices.

Also used Selenium/Sahi on occasion for acceptance tests. We need to test on
lots of mobile devices so this helped speed things up a little when using the
Android WebDriver and Appium.

I still don't feel like we've found the holy grail of JavaScript/UI testing. A
mixture seems to works best for us. Unit test what we can and using
Selenium/Sahi when testing browser/device inconsistencies are important.

------
larsthorup
I write JavaScript unit tests using QUnit on one project and Jasmine on
another. I can run thoses tests in a browser when debugging, and from the
command line for continuous integration. Unit tests are fast and much more
robust than Selenium tests. On one project we curently run 800 Jasmine tests
in less than 20 seconds. I have written a series of blog posts on the
continuous integration side of front-end JavaScript unit testing:
[http://www.zealake.com/2012/12/25/run-all-your-javascript-
qu...](http://www.zealake.com/2012/12/25/run-all-your-javascript-qunit-tests-
on-every-commit/)

------
kevinSuttle
Zombie.js on Node is a good option. A book has been written about it at
PacktPub.

[http://www.amazon.com/gp/product/1782160523/ref=as_li_ss_tl?...](http://www.amazon.com/gp/product/1782160523/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=1782160523&linkCode=as2&tag=kevinsuttle-20)

------
cjbprime
<http://theintern.io/> looks very interesting, haven't used it yet.

------
sandeep45
if you are looking to do unit tests, jasmine is definitely worth looking at.
<https://github.com/pivotal/jasmine>

