Getting Good with JavaScript - Andrew Burgess [25]
What kinds of things will the JavaScript engine throw an error on? Try calling a function that doesn't exist, or accessing a property of null; yep, you'll get an error. However, it's useful to be able to throw our own errors, so let's see how it's done:
Example 4.17
function make_coffee(requested_size) {
var sizes = ["large", "medium", "small"],
coffee;
if (sizes.indexOf(requested_size) < 0) {
throw new Error("We don't offer that size");
}
coffee = { size: required_size, added: ["sugar", "sugar", "cream" ] };
return coffee;
}
try {
make_coffee("extra large");
} catch (e) {
console.log(e.message);
}
You might find this to be a common pattern. When there's the possibility of an error, you'll throw it within a function. Then, you'll wrap the calling of that function in a try statement and catch the error, if there is one. The way it works is that as soon as the error is thrown, the program jumps to the catch statement, so nothing after the error is ever executed. As you can see, we're using the Error constructor function, passing in our error message.
Testing your JavaScript
Let's talk about testing your code. Testing is like pictures of kittens: it's impossible to have too much of it. You should constantly be testing your code. There are two main types of testing: performance testing and unit testing.
Unit testing refers to testing each bit of functionality (each unit) in your code. You may even want to use the practice "Test Driven Development," which means you write your tests first, so you know what the code you are about to write is supposed to do.
Performance testing refers to making sure you have written your code in the fastest way possible. No, I'm not referring to the length of time it took you to code. I mean the length of time is takes your code to run. It's important to have efficient code.
Let's look at each of these types of testing individually.
Unit Testing
So, testing each unit of your code: it sounds like a good idea, but how do you do it? Well, here's the basic process:
Write your tests
Run your tests and watch them fail
Write your code
Run your tests and watch them pass
Refactor (clean up) your code
Rinse and repeat for each feature
This is the process for test-driven development: by writing the tests first, you'll have a goal to work towards. Don't feel bad about failing tests; at first, you want them to fail. If they don't fail, you've probably misunderstood your goals or written poor tests.
So how do you write these tests? Often, you'll use a testing framework (we'll talk about frameworks and libraries in the next chapter). However, it's not too hard to write your own testing functionality.
Before we write our tests or test functionality, let's ask this: what types of things should we be testing for? Here are the two types of tests common testing frameworks implement:
assert: determines is something is true or not
equal: determines if two things are equal
We could write these functions ourselves … so let's do that now! Note: this will assume that you're testing your JavaScript in a web browser, because this is the case more often than not. This means we're going to deal with the Document Object Model, which you might not know about yet. Don't worry, we cover all the ugly aspects of the DOM in the next chapter. You can jump there if you'd like, or hang on for the ride. It won't be much right now, so you shouldn't have to worry.
Example test.js
var TEST = (function () {
var results = document.createElement("ul");
results.id = "tests";
document.body.appendChild(results);
function log(class_name, msg) {
var li = document.createElement("li");
li.className = class_name;
li.appendChild(document.createTextNode(msg));
results.appendChild(li);
}
return {
assert : function (bool, msg) {
log((bool) ? "pass" : "fail", msg);
},
equal : function (first, second, msg) {
log((first === second) ? "pass" : "fail", msg)
}
};
}());
Notice I'm using the module pattern to create our little testing framework.