对于javascript来说，通过单元测试，你也可以实现TDD。对你非常有好处，一是减少了js变动带来的代码退化问题，另外一方面是TDD可以改变你设计程序的方式。
举个简单的例子，写javascript很多情况下是和BOM（也就是文档模型）和DOM打交道的，这样可以说javascript程序很容易与dom高度耦合，这样的程序运行起来没有问题，但是应对需求变化的能力会比较地。但是根据人的思维方式，javascript很多时候是先出页面，然后根据页面逐渐调试着写出javascript，对于开发者来说，脑子里并不是真正的清楚自己要什么，而是在想界面的结果……这样产生的高耦合代码不容易测试，也难以面对多变的界面。
所以，换一种方式思考。如果用单元测试的方式去写，你就需要考虑程序的可测试性，这会细化你的程序的模块粒度，因为细粒度的抽象容易单元测试。同时由于js单元测试的页面是mock出来的，所以一般都会尽量的简单，这样会减少程序远对界面的依赖。同时由于界面的可测是性问题，也许会减少对element的style的修改，转而使用语义话的css。例如如果一个元素高亮，你可以element.style[‘font-size’]=’bold’;element.style.color=’red’l….，当然你也可以element.addClassName(‘highlight’)，然后那些不好验证的界面的约束条件可以放到css里面去，放给可用性和用户验收测试去验证。这样的单元测试的验证条件（assertion）会简单很多，如果写过单元测试的朋友肯定会有感触的。
那么，常见的Javascript的单元测试框架有JsUnit和scrit.aculo.us的单元测试框架两个。前者方便用ant调用和分析结果，适合使用了ant的项目。而后者的优点就是界面好看，直接运行产生的报告清楚漂亮。所以小型项目我倾向后者，而大型项目我倾向前者。当然，由于js的动态特性，其实做个单元测试框架非常简单，所以自己动手也无妨。关键是要写，而且争取做到测试先行。
前面是个引子，其实写这个的原因是今天上午的一个郁闷的事。
前面的blog entry说道我升级了Firefox3，结果遇到了getElementsByClassName问题。但是今天换到另外一个项目组，没有用那个方法，程序也正常。可是我TDD的写一个新的feature的时候却发现可爱的JsUnit的testRunner在Firefox3里面无法工作，从firebug里面看到了一堆安全性问题。估计是firefox3的新安全模型造成的吧。那么，由于firefox3覆盖了firefox2，所以难道我没法写程序了？当然不可以，还有safari嘛。马上开始去写测试了，写好测试执行测试，发现红条。嗯，很满意，因为TDD的红－绿－红－绿的节奏就是这样的。然后我开始去写实现来满足这个测试……结果忙活了一上午就是不行……而且发现一些原来的测试也无法通过了……我仔细寻找问题，diff修改的内容，可是最后实在没有发现任何让它不能通过的原因，因为手工在firebug里面都已经验证了写的实现是没有问题的呀……崩溃。此时我突然想起来我们的持续集成服务器里面没有跑safari的JsUnit测试……也就是说不能确定在safari下全绿（此时的背景是我们的持续集成显示全部绿色，也就是说所有的测试都可以同过，包括windows和linux平台还有IE及Firefox），那么我可能衰了。马上开动camino（靠，一上午都忘记用它执行JsUnit了，因为我的习惯是Camino里面保存to read list），运行一下全绿。很兴奋，但是感觉刚才寻找问题的1个多小时被无辜的浪费了，心疼呀。
那么，请注意啦，我只是想提醒，jsUnit可能不能在safari下正常工作（大部分测试没有问题，少量在其它浏览器正常的测试在safari下无法工作），我用的是safari3.0.4……