What Should I Test When I Write Software?

code | 6-6-2013

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.

Terminal



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.



About the Author

Tyson Cadenhead is a Senior JavaScript Developer at Aloompa. He lives in the greater Nashville area. His specialty is writing large, scalable JavaScript applications on the client and server side. His passions are for good design, usability, and clean, reusable code.

Tags: Testing Mocha QUnit Selenium

Related Posts:

comments powered by Disqus

Don't Miss Anything!

Sign Up For My Email Newsletter

I Wrote a Book!

Popular Posts