As seen onFavicon for undefinednull

What's making it hard to get started with JS testing?

I asked on Twitter what was keeping people from testing their JavaScript, and I heard from devs from a variety of experience levels and backgrounds. Here's what they said.


  1. Which tool do I use?

  2. Testing frameworks generally come in a couple of flavors: assertion-style tests (a la QUnit) and "behavior-driven development" style tests. The former style is terse; the latter is more "conversational" ... or else "pointlessly verbose," depending on your point of view. 
  3. I understand the opposition to BDD's verbosity, but I think that the super-terse style can be intimidating to newcomers, whereas the BDD style is a lot easier to read and understand what's going on if you're new to testing. Which one is "right"? Whichever makes you want to write tests, as far as I'm concerned. For ultimate flexibility, tools like Mocha let you pick the style that suits you.
  4. Will testing slow me down?

  5. Krzysztof Szafranek wrote a great post about unit testing JavaScript recently, and he has a good discussion of the "it takes too long" argument. TL;DR: put in the time now to write tests, or put in the time later to detect and fix bugs and regressions.
  6. The code we've learned to write isn't testable

  7. This was one of my biggest struggles when I started to consider writing tests for my JavaScript -- what the heck was I supposed to test in my beautifully chained jQuery code? My suspicion is that this need to rethink how code is written is the biggest hurdle to overcome when it comes to writing tests.
  8. What does testable code look like? Loosely coupled modules with simple methods that do one thing and do it well. Put another way: if a method is more than 10 lines long, it's pretty likely that it's doing too much. Another thing: When you start thinking about tests, you'll start thinking about how to generalize your code and how to share abstractions across modules. For example, here's a base View module that I wrote for a Backbone demo app, and here are the tests that prove that it works. Individual views that use this View module as their starting point don't need to test the functionality it provides -- they only test what's unique about them.
  9. If you're writing code from scratch, the 10-line rule is a decently easy habit to embrace if you're intentional about it, but existing code presents much bigger challenges; if existing code is poorly organized, you simply can't write tests without rewriting the code itself. The good news: a rewrite doesn't have to be a massive, all-hands undertaking. You can find small chunks of code and start applying better practices to it by breaking functionality out into smaller pieces, and then writing tests for those small pieces. Remember that some tests are always better than no tests.
  10. What do "good" tests look like?

  11. Looking at the unit tests from established open-source projects can be really informative -- I remember being pretty surprised at how basic some assertions are, but even basic assertions can be valuable in rapidly identifying and fixing regressions.