found drama

Right off the bat, and just so we’re clear about this: I read an “Early Release” edition of Mark Ethan Trostler’s Testable JavaScript, and in a lot of places… it shows. I’m sure it will come through editing and be a lot tighter by the time you read it. ¹

Putting its rough “Early Release” nature aside, I had some mixed feelings about this book. I’ll try to explain it as follows:

Rebecca Murphey (@rmurphey) did a talk during the 2012 JavaScript Summit (put on by E4H) which was titled “Writing Testable JavaScript”. ² Early on in that talk, she impressed upon us that she was going to talk about how to write testable JavaScript, and not how to write JavaScript tests, nor how to test JavaScript. These are important distinctions. Writing tests (in a way) is this weird hybrid of somehow both writing more code and writing documentation. And testing your code is … well, it’s the act of putting your code through the accompanying tests to see if they pass muster. But writing testable code is about adopting a certain style wherein your code becomes easier to test as a consequence of that style. And the argument goes that if your code is easier to test, then it will also be easier to reason about. (Insert functional programming rant here.)

Anyway…

Trostler talks about this (i.e., writing “testable” code), but not nearly at the length I was hoping for. Whereas Murphey kept her talk focused on adopting testable styles, ³ Trostler’s book manages to be about writing testable code and writing tests and running tests and automating and more. Given the title, I was expecting him to go deep into that functional style, to really meditate about decomposing functions into discrete units, to wax philosophical (and practical!) about how to reason about problems, etc. And it wasn’t even that this was missing, just that he was more/less finished talking about that by (say…) Chapter 3.

From there, he takes us on a tour of the rest of Test Town: writing unit tests, writing integration tests, generating code coverage statistics, performance testing, load testing, debugging, linting and code quality, and how to bundle it all up and automate it with your build tool. Somehow this was both too much information and not nearly enough at the same time. For example: there is a whole chapter dedicated to code coverage, and yet I walked away from it not really sure if I knew how to do that kind of instrumentation, nor if I fully understood the value. For example: integration testing, performance testing, and load testing are all jammed in to one chapter, but should probably have been split into separate chapters, and/but he also starts talking about things (e.g., generating HAR reports ⁴) which are… not really about testing JavaScript, strictly speaking.

I think maybe that’s where I got my first real taste of those mixed feelings. I’ve been looking at a lot of front-end performance stuff recently, and so I’m very interested in it. But talking about “wire weight” is not what I think about when I see a book titled Testable JavaScript.

At any rate, lest this turns in to an off-color and off-topic rant: I reconciled my mixed feelings about the book in a mostly positive manner. The things that are outside the scope that’s implied by the title are all things that any front-end engineer worth her semicolons should be fussing about anyway — so that’s all well and good. And I see here in my notes a snarky remark about “suggested alternative title: Testing JavaScript with Y.Test” — but that’s a little unfair of me. ⁵

Overall, this book (and books like it) need to be written for front-end engineers. We need this badly, and I’m happy to start seeing these books crop up. (Christian Johansen’s ⁶ Test-Driven JavaScript Development is supposed to be great; ⁷ and James Coglan (@jcoglan) just announced his JS Testing Recipes.) This is the sort of thing that we need to see more of in our discipline.

So that being said:

My hat is off to Trostler for furthering the conversation; and/but: his editor has some work ahead of them both.

(Note: for once I did not receive an electronic copy in exchange for writing a review; this one I wrote because I felt like it.)

1. I promise?[↩]
2. The slides for her talk are available on Speaker Deck. See also: portions of Nicholas Zakas’ Maintainable JavaScript talk.[↩]
3. Granted: it was a one hour talk, so… much more focused.[↩]
4. Check out this video with Ilya Grigorik and Peter Lubbers for an interesting discussion about HAR. (Optionally: Ilya’s accompanying blog post.)[↩]
5. I’ve come to prefer Jasmine, and so naturally I’m annoyed that my favorite testing tool is included in the strangest possible manner.[↩]
6. Lead author of Buster.js.[↩]
7. But I don’t know for sure… I haven’t read it myself.[↩]

About Rob Friesel

One Response to review: Testable JavaScript