What should I test when I write software?

Posted on June 6, 2013 by tysoncadenhead

Testing is really important when you write software. That is a fact. But the real question is what you should test. The simple answer is "everything possible."

A more fleshed out answer is that you should also avoid testing the same things multiple times.

For example, if you are testing your server-side API on the server, it would be redundant to test the entire API with client-side ajax calls as well.

Here are some of the basic places where tests are most important during the application life-cycle.

Server-side unit tests

Your server-side code is the building block of your application. If the server-side breaks, everything breaks.

You will definitely need to write tests to cover any place where you are taking parameters and returning a value or an array of values. The specific implementation will depend on your server-side stack, but if you are writing code with an MVC structure, all of your models, controllers and helpers should definitely have extensive test coverage.

Mocha JS

My server-side language of choice is Node.js, and I would recommend using Mocha and Chai as a testing suite.

Client-side JavaScript unit tests

It has become increasingly important to cover your client-side code with unit tests. Like the server-side tests, client-side JavaScript unit tests should cover any method that returns a value of any type.

QUnit

There are a ton of great options for unit testing your JavaScript, but a flow that I've found works really well for me is to write my tests in QUnit and then run them from the terminal using a cool utility called Thrill. Thrill sits in your browser and waits for a testing worker to spawn. The really cool thing about Thrill is that you can test multiple browsers really quickly and painlessly without even looking at anything but the terminal.

Screen Shot 2013-06-06 at 1.04.05 PM

UI tests

Testing the user interface can be a tricky. As hard as I've tried, I haven't found a better solution than Selenium. Luckily, there is a Node.js api for Selenium, so you don't have to write in Java to run your tests in multiple browsers.

Selenium

The main things that you'll want to write tests for is the ability to read, write and update data in your UI. If your selenium tests break, you'll know that users aren't able to experience your application in the way it was intended.

Manual tests

Unfortunately, you can't rely solely on your unit tests to insure that your application works. You will actually need to look at it in a browser.

Live Reload

The best tools to streamline the manual testing process are a combination of LiveReload, which automatically updates the content of your browser when you change your code, and Adobe Edge Inspect which can sync your mobile devices with what you are seeing in your desktop browser so that you can insure that your application looks good on multiple screen sizes and device types.

Usability tests

Usability tests are probably the most tedious because they can't be automated. The idea is to put a real person in front of your application and see whether or not they can easily perform basic actions.

There is a really good book called "Rocket Surgery Made Easy" by Steve Krug that walks you through how to conduct usability tests. I highly recommend it.

Getting good test coverage on your application is not a small undertaking, but I have found that it actually saves time in the long-run, because it keeps you from breaking things in the process of fixing other things.

jquery.jsonTemplate

Posted on June 3, 2013 by tysoncadenhead

jQuery JSON Template This is entirely experimental, but I've created a purely JSON-based templating system called jQuery.jsonTemplate.

The idea is to have a completely JSON-based nested markup language that compiles to HTML and back again.

Using it is pretty simple. You just need to add all of the properties you would typically use in HTML to the JSON structure like this:

 
$("#my-element").jsonTemplate(
    [{
       type: 'h1',
       content: 'Hello World'
    }]
);

The code above would append this to the element with an id of "my-element":

 
<h1>Hello World</h1>

You can even do nested elements inside of each other like this:

 
$("#my-element").jsonTemplate(
    [{
       type: 'div',
       items: [{
            type: 'p',
            items: [{
                type: 'strong',
                content: 'Hi there!'
            }]
       }]
    }]
);

You can easily convert HTML to the jsonTemplate format as well:

 
<h1>Hello World</h1>
<script type="javascript">
  var template = $("h1").jsonTemplate();
  console.log(template); // { type: 'h1', content: 'Hello World' }
</script>

The basic idea behind a templating language like this is that it could be primarily driven by JavaScript and you could use all of the methods in JavaScript to manipulate the data before you render it with jsonTemplate. I'm not sure that it necessarily has an advantage over the string-based templating languages like EJS or Mustache, but it was a fun little project to knock out. I'm considering porting this for Node too, if there's any interest in it.

Since I used all of the attributes that HTML gave me out of the box and only tacked on a few attributes like "content" to render the HTML, "items" to render an array of items in an element and "type" to determine the element type, the code is only a couple hundred lines long even when it's uncompressed.

I'd be interested to see what other people think of this little jQuery plugin and whether anyone is able to find practical uses for it.

If you'd like to check it out, here is the project on Github

Compound JS Presentation in Nashville

Posted on May 18, 2013 by tysoncadenhead

If you're going to be in Nashville on May 21 at 6:00, stop by the Interactive Developers meetup at Vaco to hear me speak about the Compound MVC framework for Node. There is always free food and drink. You can RSVP here.

Update:
Now that the presentation is over, you can see my slides here.