

JavaScript Testing Tactics [video] - falava
http://blog.testdouble.com/posts/2013-10-03-javascript-testing-tactics.html

======
paultannenbaum
For anyone that is looking to get better at TDD with javascript, I highly
recommend James Shore's webcast site:
[http://www.letscodejavascript.com/](http://www.letscodejavascript.com/)

~~~
jdlshore
Thanks for the plug! :-) I hang out^H^H^H^H^H^H^H^H spend far too much time
here on HN and I'm happy to talk about testing JavaScript all day long, if
anybody wants to know more.

------
clarkdave
I tried switching to (Iced)CoffeeScript to write tests (using Mocha and Sinon)
for a Node app (written in JS). It went something like:

Week one: this is awesome. It's so clean!

Week two: asynchronous stuff is still an utter pain though. Hey, what's this
IcedCoffeeScript...?

Week three: Wow, ICS is great. My tests look like Ruby & rspec now!

Week four: ICS produces unholy Javascript and unintelligible stacktraces. I've
lost count of how many hours I've lost trying to figure out which line
triggered a test to fail. Let's switch back to CoffeeScript and use async.

Week five: Still fed up not being able to identify which line failed at a
glance, and have been bitten more than once by CoffeeScript's indentation
causing subtle errors, which is easy to confuse if you do any copypasting
within `describe` blocks.

Week six: I'm just going back to straight JavaScript. It's a pain but it does
the job.

I've since given up on being able to write tests in Node.js with the same
elegance/ease as I can with Ruby & rspec.

I still dig CoffeeScript, but now I only use it for client-side stuff. And as
for IcedCoffeeScript, that has found a place in my toolbelt for small scripts,
where its speed to write and lack of noise are worth the trade off in
maintainability.

------
shtylman
What I wont do: Use a totally different language to write my tests.

~~~
pselbert
The term "totally different" is a bit exaggerative here. I hadn't clicked
through the slides, but after reading your statement I wanted to see what
crazy "totally different" language was being used to test.

Really, a transpiled language isn't much of a stretch.

Edit: Fixed spelling typo.

~~~
shtylman
It is a stretch because it has different semantics and behavior. It also means
that anyone that comes along to contribute or work on the project that knows
JS now has to learn coffeescript and any random details that brings to work on
your JS project. This doesn't really make sense to me. Just use JS or CS but
both in the same project?

~~~
tieTYT
I barely knew javascript before I learned coffeescript. Now I know both pretty
well as a result. coffeescript compiles to really readable javascript anyway
(yes, that's subjective).

I use both in the same project. For example, I have a gruntfile written in
javascript. It's easy for me to modify it. The rest of my code is in
coffeescript. It's easy for me to modify it.

I think this is a really superficial line for you to draw in the sand. Use the
best tool for the job. When you build a house, you end up using more than one
tool.

------
lucaspiller
Shamless plug: Fed up with there not being a dead simple library for stubbing
stuff when writing Javascript tests in Jasmine (I come from the Ruby world), I
wrote Why.js. It let's you stub anything and everything, and is optimised for
tests written in Coffeescript.

Example:

    
    
        why.stub 'User.find', (userId) ->
          { name: 'Bob' } 
    

[https://github.com/lucaspiller/why.js](https://github.com/lucaspiller/why.js)

~~~
tieTYT
Why (no pun intended) should I use this over sinon?

~~~
lucaspiller
I should probably add that to the readme: I was using Sinon for other stuff
(mainly the spies to check stuff is called), and wanted to mock a call to
X.Y.Z. This was an external component with it's own tests, so for test
isolation it wasn't included in the environment for this test - as such X.Y
and X.Y.Z didn't exist. Sinon has the mock function, but you can't call it on
stuff that doesn't exist. I guess you could stub X to include Y then stub that
to include Z but it seems a bit overkill. Also coming from a Ruby background
I'm not a fan of Sinon's quite verbose syntax. So I quickly whipped this up to
do what I wanted :)

------
ganarajpr
@Author : What you should do ?

Use Angular. Every single thing you mentioned there is covered. Except
coffeescript, but thats unrelated anyway.

Whats covered ?

Async code : check. ( timeout flush )

Wrapper for XHR : check ($httpBackend ).

DOM abstraction : check ( No DOM Manipulation in controllers! )

fast feedback : check ( karma ) .

------
briantakita
Re: Tests for Design Feedback. I used to follow that approach, but I found
that it locks you into the implementation and adds unnecessary drag when
refactoring.

Now I like to think of tests as black box and white box. I prefer black box
tests because it tells me if the system works from the api or interface, while
giving me the freedom to refactor and reimplement without unnecessary drag.

Now for my Shameless plug. If your test suite has lots of edge cases, the test
suite takes a long time to run because the same setup logic is being run many
times.

I created jasmine-flow to reduce the number of times the setup logic is run by
reorganizing the tests into linear flows. [https://github.com/btakita/jasmine-
flow](https://github.com/btakita/jasmine-flow)

I sped up my test suite about 10x (~400 seconds to ~40 seconds) doing this.

I know, it's not 1 second, but since these are black box tests, I know if
things work in reality. What is really important for development flow is
running individual tests quickly (< 1 second).

