JSLint ? hatred : gratitude

"Parker-Big-Red-Duofold" by batch1928_44 - Own work. Licensed under Public Domain via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Parker-Big-Red-Duofold.jpg#/media/File:Parker-Big-Red-Duofold.jpg

Last weekend, I decided to try adding JSLint to my JavaScript editor’s workflow.

For those not familiar, JSLint is like that elementary school teacher who enjoyed using their red pen just a little too much when they graded your essays.  Except JSLint doesn’t care about mismatched verb tenses or dangling participles– it cares about things like undeclared variables, consistent space indentations and unexpected ‘++’ usage.

I should mention, the creator of JSLint (Douglas Crockford) boasts his program will hurt your feelings. And he’s Continue reading “JSLint ? hatred : gratitude”

Unit Testing JavaScript with QUnit

"Neti pot". Licensed under CC BY-SA 3.0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Neti_pot.jpg#/media/File:Neti_pot.jpg

Unit testing is like nasal irrigation. Many experts agree it is beneficial, but when the time comes to make it a regular part of your daily routine– everyone suddenly has “more important things to do.”

(Pardon the comparison, but this is the first weekend of spring. I’m under the weather with allergy/sinus troubles– which should explain both the simile above and my current frame of mind.)

I’ve sporadically dabbled with unit testing before, but it’s been more of an afterthought. Based on what I’ve read, adding a test framework to an existing JavaScript project is more difficult and frustrating than using a test framework from the initial development stage. I suspect that’s why most people think unit testing is . . . about as appealing as nasal irrigation.

(You were wondering if I was going to work that back in, weren’t you?)

Since I was sick and housebound, however, I decided forced myself to try out the QUnit framework for JavaScript unit testing. I even had a simple JavaScript project handy (my satirical FizzBuzz object) that was sufficiently “atomic” for the task. The only modification I had to make was converting the play() method from sending output to console.log() to populating an array that got returned to the calling function.

I won’t walk you through downloading and installing the QUnit framework, or the obvious tests (e.g. are the default values of the properties what we expect them to be when the object initializes).  That’s what the QUnit documentation is for, and I encourage you to read and familiarize yourself with it.

For me, the tricky part was figuring out how to test the individual items within the returned array, to make sure each one was a valid response (as opposed to “undefined”, for example).  After several false starts, I realized that by combining a for loop inside of a QUnit test along with JavaScript’s OR operator inside of the assert.ok() method invocation, I could verify each element’s value was either the expected integer, “fizz”, “buzz”, or “fizzbuzz.”


QUnit.test( "check individual results", function(assert){
for (x = fizzbuzz.start; x <= fizzbuzz.finish; x++) {
assert.ok(
(results[x] == x) ||
(results[x] == 'fizz') ||
(results[x] == 'buzz') ||
(results[x] == 'fizzbuzz') , "We expect results[x] is equal to x, 'fizz', 'buzz', or 'fizzbuzz.'");
}
});

(Note: I have considered putting all the valid responses in an array and testing with an indexOf() method. Unfortunately, when indexOf fails to locate its target, it returns a value of -1 . . . which happens to be true in JavaScript, and would cause the assertion to actually pass instead of fail. Go figure.)

Is anyone else trying to add unit testing to their workflow/routine?  If so, what tricks have you learned? Let us know in the comments below.

How A Simple Algorithm Goes Straight To Hell

"Oskanpur-1" by Oskanpur - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Oskanpur-1.JPG#mediaviewer/File:Oskanpur-1.JPG

Several years ago, the Oatmeal did a fabulously hilarious poster that showed how a website redesign starts off on the right foot– only to become completely derailed into a horrible abomination by client feedback and endless revisions.

Web Development is more efficient. We don’t let client feedback mess up our code. Instead, we screw it all up by ourselves.

Ladies and Gentlemen, I present to you the “FizzBuzz Problem.”

Disclosure: I went through a job search in 2014, and no one asked me to solve the FizzBuzz problem in a job interview. The only reason I’ve heard of it is because it was mentioned on Quora. Personally, I think it sounds condescending and alienating, but it makes a great example of “HOW A SIMPLE ALGORITHM GOES STRAIGHT TO HELL!”

Shall we get started?

Continue reading “How A Simple Algorithm Goes Straight To Hell”