Feb 25, 2016 17:43 · 719 words · 4 minutes read JS jasmine testing self-describing

[Note: this is one of a couple of things I plan to fish out from the old version of the web site. More will follow. Or won’t. We’ll see. - TCB]

I’m an old, silverback nerd. I remember the dreamtime when men could talk to animals and giants walked the earth. In many ways, of course, that’s good. Lots of strange error codes and mystical microsoft mumbo jumbo seems natural and sane to me, even if it shouldn’t. But sometimes it also means I miss out on things that I should know, and then ignore them long past a time when I should have paid attention. One of those things, I am sad to admit, is programmatic testing.


When I was a wee nerd, barely formed and blinking at the bright lights of a new world, we didn’t test our code. Or rather, we tested our code by running it once or twice on a system we never used called ‘testing’ and then uploading it to production. If anyone called us right away, we had a problem. If they didn’t, we didn’t. In a small group of developers, with a reasonably sized application, that can work surprisingly well. Certainly better than a lot of testing zealots might say.

It’s a much different story when working with a larger group of nerds, distributed across the world, each with his or her own history and talent(s). I believe that is a core reason why testing has become so important in the free software world. Working with widely distributed developers, some (many? all?) of whom are strangers is a very different creature than working with people a desk or an office away. Testing also doesn’t just add tests, it substitutes as very basic documentation. Reading a test is (usually, one hopes) at least a bit easier that reading code when it’s time to figure out what someone expected a piece of code to do.

In light of this I was working on something where the core unit tests were written using the Jasmine testing framework. So, off I went to find the basic documentation.

Few concepts are closer to a nerd’s heart than recursion. Ask any serious nerd what she has learned from the strange incantations we have to write, and the ability to think recursively will almost always be high on the list. But there are other things that have to be forced into a brain to do this stuff, and it’s not just an outlandish respect for punctuation. One of those crucial concepts either is, or ought to be, self-description.

Probably the most common example of a self-descriptive object is a coffee table art book. A book that is about beautiful art ought to, in itself, be a beautiful work of art. While that is the canonical version of self-descriptive, my personal favorite version of a self-descriptive object is a hammer. A hammer needs no instructions. When archaeologists find a hammer during a dig, even if it’s 2500 years old, everyone knows it’s a hammer. Nobody wonders if it might be a writing tool or an earring. Nobody has ever needed a hammer, then found a hammer and thought to themselves, ‘What should I use this thing for.’

Trying to find my testing hammer I went to the introduction page for jasmine. It is nearly hammer-like in the degree that it is self-describing. The page is split into tow ‘panes.’ On the left side is very, very basic explanation of what happens in the right part of the page, which is color-highlighted code. At the bottom of the page are results, from Jasmine itself, of all of the tests written on the page.

Want to learn Jasmine basics? Set up a simple gulp job to run the tests and spit results out to the terminal terminal output, then type the tests on that page into a file. Each time you save the file, the tests run or don’t run, and by the end, voila, you know the basics of how jasmine works. Not sure how one test ought to run? Look at the results on that page and see the correct output. I’ve spent a lot of time reading nerd stuff over the years, and that page is one of the finest bits of documentation I have ever seen.