Testing or: How I Learned to Stop Worrying and Write JavaScript

I’m one day over six weeks in to a six-month web development program at the Nashville Software School. The first three months of the program are dedicated to Front-End development. This boils down to About two weeks of HTML and CSS, and the rest of the time in JavaScript. If HTML is the content of the web and CSS is the presentation, JavaScript could be called the behavior. It handles manipulating the web page you view, interacting with the forms you fill out, and creating the pop-ups your browser blocks. So about two and a half months training seems about right.

Over the past couple of days we have been covering testing in JavaScript. Test Driven Development is, according to Wikipedia:

a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test…”

Write a test, write the least code you can to get the test to pass, rinse, repeat. It is a simple idea that has turned out to be a difficult one, for me at least, to implement. Say you want a simple function that when called returns the string (series of characters) “world”. Just for fun you’re going to call this function “hello.” What would be your first step? In TDD it might be something like this:

describe('hello', function() {
it('should return world', function() {

For starters, this test is written using the MochaJS testing framework and the ChaiJS assertion library. These are simply tools that let us write tests that make sense when people read them. So when you read the test above, line by line, you may be able to figure out what needs to happen. I need a function that, when called, returns a string that equals ‘world’. So let’s do this.

function hello() {
return 'world';

Huzzah! We have not only a usable function, but a test that verifies that this function indeed works. Good on you!

This is an overly simplistic example of TDD and what we’ve been doing in school these past couple of days (and perhaps what I should be doing now instead of writing this). But I wanted to go through it to talk about something I’ve mentioned to a few folks today. Two weeks ago if you had asked me to write an app that takes in several inputs and stores them in a database to be retrieved later I would have lost it. There’s no way I could have done that. I mean, sure, I made this awesome site:

But there’s no way I could make something actually interactive and worth somebody’s time. But after a couple of weeks of, seemingly, banging my head against the wall of JavaScript I had absorbed some things. So when I sat down to write an address book app the actual writing of the app wasn’t too much of a reach. I had the base HTML boilerplate up in no time, and the general behavior down. But what I hadn’t done is write any tests. I just figured I’d get to it later, no problem. And now that later is here I’ve learned that it seems like it would have been easier to write those tests from the git go.

My hope is that in a couple of weeks I’ll be at a point where I will be able to conceptualize a project in such a way that I can write tests, write code, and build. It does seem like a good way to get off the ground…I’m just not quite at that level yet.

So for now I need to get back to writing tests for code that I know works, and hopefully writing more for code that doesn’t exist yet. Thanks for reading.


One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.