Which tool do I use?
- 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.
- 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.
Will testing slow me down?
The code we've learned to write isn't testable
- 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.
- 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.
What do "good" tests look like?
- 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.