JavaScript Testing Tactics [video] | Hacker News Reader

JavaScript Testing Tactics [video]

blog.testdouble.com

29 pointsfalava12 comments

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

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.

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.

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

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.

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?

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.

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

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

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 :)

@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 ) .

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

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

Reply on news.ycombinator.com