当然，我相信你一定会对自己的代码进行测试。没有人会在写完一大片代码之后，不经过运行就放到线上产品中。我的这篇文章主要还是想强调一下如何做测试。如果你并没能做到自动化测试，那么请你准备接受一次提高生产力和信心的洗礼。
提醒：我会在本文中提到单元测试和TDD。如果你已经对这些内容有所了解，那么你可以跳过下面这几条学习测试的理由而直接阅读后面部分，或者至少阅读结尾部分“你需要注意的理由”。
● “我使用了类似jQuery这样的框架，这样已经能够确保我的代码工作正常。”
● “测试对于那些支持者而言是高级实践，但对于我来说不是”
● “测试需要花费太多时间，我更愿意为产品编写代码”
不同的目的对应不同的测试
测试包含了太多的内容，测试的方式也取决于你进行测试的目的。下面有几种测试方式，你可能会在你的应用中使用：
● 可用性测试
● 性能测试
● 稳定性性/回归测试
在本文中，我们会专注于稳定性和回归测试。换句话说，这类测试可以确保你的代码执行正确，并且不包含bug。在大部分情况下，绝对没有bug是不可能的。我们可以做的是采取一些有效措施来减少bug的数量，并且阻止老Bug的复现。
你是如何寻找bug的？
程序员通常都需要应付程序的验收和bug的修复。在过去，这样的任务差不多都是通过调用alert然后刷新浏览器来检查变量的值，或者观察脚本的执行是否和期望的一致。
现在，大部分浏览器内置一个强大的控制台工具。对于那些没有内置控制台的浏览器，你也可以使用含有类似功能的Firebug Lite。调试过程基本类似：在代码中调用console.log，刷新浏览器来观察结果是否和期望的一致。
调试：一个例子
这里有一个调试用例，一个jQuery插件，用于将一个含有datetime属性（HTML5中的time元素）或者含有自定义属性data-datetime属性的元素中的innerHTML改为更容易人们阅读的字符串（比如：“3 hours ago”）。
| jQuery.fn.differenceInWords = (function () { var units = { second: 1000, minute: 1000 * 60, hour: 1000 * 60 * 60, day: 1000 * 60 * 60 * 24, week: 1000 * 60 * 60 * 24 * 7, month: 1000 * 60 * 60 * 24 * 30 }; function format(num, type) { return num + " " + type + (num > 1 ? "s" : ""); } return function () { this.each(function () { var datetime = this.getAttribute("datetime") || this.getAttribute("data-datetime"); var diff = new Date(datetime) - new Date(); if (diff > units.month) { this.innerHTML = "more than a month ago"; } else if (diff > units.week) { this.innerHTML = format(Math.floor(diff / units.week), "week") + " ago"; } else { var pieces = [], num, consider = ["day", "hour", "minute", "second"], measure; for (var i = 0, l = consider.length; i < l; ++i) { measure = units[consider[i]]; if (diff > measure) { num = Math.floor(diff / measure); pieces.push(format(num, consider[i])); } } this.innerHTML = (pieces.length == 1 ? pieces[0] : pieces.slice(0, pieces.length - 1).join(", ") + " and " + pieces[pieces.length - 1]) + " ago"; } }); }; }()); |
