Archives for posts with tag: testing

I’ve recently spent quite a bit of time working with QUnit, a great unit testing framework for Javascript. While building out a larger test suite, I ran into a few issues, especially while testing/working with dependency managers and the QUnit test framework. In this post I’ll document some of the issues I ran into, some patterns I started using, and a few tricks I used to ensure consistent and reliable test results. The main issues I ran into were caused by the fact that I was testing modules that were being loaded asynchronously. This meant that in some cases QUnit would miss tests, misplace module labels, and/or report false positives. Now when I mention async here, it is not to be confused with QUnit’s native support for asyncTests.

Problem #1: QUnit.done misfiring

QUnit.done = function(qunitReport) {
setTimeout(function() {
  test("helloworld", function() {
    expect( 1 );
}, 100);

Read the rest of this entry »

I love the color pink/purple - I change my syntax highlighting colors so that I comment more...

One day, a software developer was walking down the street and came across a large pill of dog shit.  He bent down to get a closer look and said to himself “yep, that looks like shit”.  He then gave it a sniff, and said “Yep, that smells like shit”.  He then put his finger in it, and said “Yep, this feels like shit”.  Finally he did the unthinkable and tasted his finger and happily said: “Oh yeah, that tastes like shit…”.  He then walked away satisfied, and said out loud:

“That was definitely dog shit.  Good thing I didn’t step in it!”

An old joke which I managed to re-arrange and fit into my experiences with software.  Sometimes you have to taste the shit to avoid stepping in it. Don’t look too deeply into the metaphor.  Testing is hard, not everyone wants to do it, but it is your duty to prepare for and handle the worst, so your customers don’t need to.  I guess there is a hidden message about thoroughness too.