单元测试101：你测试你的javascript吗？(6)

　　21. pieces.push(format(num, consider[i]));

　　22. }

　　23. }

　　24.

　　25. humanized = (pieces.length == 1 ? pieces[0] :

　　26. pieces.slice(0, pieces.length - 1).join(", ") + " and " +

　　27. pieces[pieces.length - 1]);

　　28. }

　　29.

　　30. return future ? "in " + humanized : humanized + " ago";

　　31. };

　　注意，我没有碰jQuery插件。因为我们分离了无关的部分，我可以完全自由的修改和提升人性化字符串的方法，而不改变我的网站中jQuery使用人性化字符串的方法。

　　持续集成

　　TDD实践中，我们需要及时的反馈。反馈来自我们的测试，这意味着测试需要运行的轻松快速。JsTestDriver已经使测试运行的容易而快速，但总有局限性。限制来自多浏览器的形式。JsTestDriver能如你所愿在多个浏览器上容易的运行测试，因以下两个原因，这对TDD工作流这样做是不便的：

　　每一次从多个浏览器得到测试报告，使它更难看到发生了什么，并失去了TDD给你带来的便利。

　　一些较弱的浏览器，而通常是重要的测试对象，是缓慢的。我的意思是慢的足以毁灭TDD流程。(And I mean slow.Slow ruins the TDD flow.)

　　解决这个问题的一个方案是持续集成。持续集成是自动和经常进行产品质量控制的实践。这时应该包含进来一些工具，如JsLint，而它当然应该包含运行测试。

　　一个持续集成(CI)服务器可以确保所有开发者的工作可以正确的组合，并且负责在指定的多个浏览器是执行测试。一个构建的CI服务器通常由版本控制系统触发，如Git或Subversion，并且一般提供当发现问题时给项目成员发送邮件的功能。

　　我最近写了为JsTestDriver创建Hudson CI服务器指南。使用Hudson和JsTestDriver，很容易创建一个高效高质量的工作流程。对我自己而言，我基本是做什么都是TDD，通常我在本机的Firefox上运行测试，它是我发现具有最好错误信息和跟踪信息的浏览器。每次我完成一个功能，通常很小，我把它放到代码库中。这时，Hudson检出我刚提交的变化并在广泛的浏览器上运行所有的单元测试。如果有测试失败，我会收到一个说明发生了什么的邮件。此外，我可以随时访问Hudson服务器查看项目构建视图，看个人的控制台输出等等。

　　结论：为什么我要关心

　　如果，在阅读完这篇文章之后，你还不确信单元测试是一个很值得做的实践，让我们再重述一下一些常见误解。

　　我使用一个库，如jQuery，它确保我的代码正确的工作。

　　Ajax库，如jQuery，在帮助你处理跨浏览器问题上走了很远。实际上，在很多情况下，这些库完全抽象掉了所有这些讨厌的DOM缺陷，甚至是核心JavaScript的差异。然而，这些库没有，而且不能，保护你的错误的应用逻辑，而单元测试可以。

　　测试是对专业人员的高级实践，不适合我

　　我的立场是无论你认为你写代码的过程是哪种方式，你都在测试它，例如，通过刷新浏览器来验证是不是按它应该的方式工作。你简单的选择了不参与自动化和提高你的测试过程，并且在长时间运行(或不那么长时间的运行)中，你花费时间在猛击你的浏览器刷新按钮，而我花费时间写测试，然后我可以今天、明天或明年愉快的运行它。

　　像任何新技术一样，测试需要实践，但不需要一个“忍者”去做。测试由大量简单的语句组成，他们使用你的代码并对它做假设(真不好表达，原文：ests consistlargely of dirt simple statements that exercise your code and make assumptionsabout it.)。困难的部分是良好设计的代码并确保它是可测试的。换句话说，困难的部分是提高你的编程技巧并写之前思考你的代码。无论是专业人员或初学者，任何人没有原因不想提高

　　测试太花时间了，我只想写产品代码

　　手工和自动化测试都花时间。但是，不用花一两个小时“评估”单元测试和/或TDD，然后决定它是在浪费时间。单元测试和TDD需要的是实践，像其他任何科目一样。没有办法几个小时内做到擅长良好的自动化测试。你需要练习，而一旦掌握，你就会认识到我这里说的好处，并且认识到手工测试是多么的浪费。此外，如果你写了单元测试，并花一些时间严厉测试你的代码，你会选择什么呢?失败的真快，或能成功吗?

　　调整你的需求

　　从这篇文章中你可能得到这样的印象，我觉得各个人都应该采用我的工作方式。我没有那种感觉。但我感觉认真对待应用的质量和正确性是很重要的，并且我认为单元测试是实现的完整部分。(I do think thatunit testing is an integral part of that equation.)

　　这里TDD更多是一个可选部分，但我的经验告诉我，TDD极大的简化单元测试。在我实现功能之前，它帮助我提升代码设计，帮助我只实现那些必须实现的代码。当然你可以采用其他的方式也很好的实现这个目标，但是对我来说，TDD是个完美的方案。

　　现在开始实践吧!

　　About the Author

　　Originallya student in informatics, mathematics, and digital signal processing, ChristianJohansen has spent his professional career specializing in web and front-enddevelopment with technologies such as JavaScript, CSS, and HTML using agilepractices. A frequent open source contributor, he blogs about JavaScript, Ruby,and web development at cjohansen.no. Christian works at Gitorious.org, an open source Git hosting service.

　　Find Christianon:

　　§ Twitter - @cjno

　　§ Christian'sBlog

　　§ Christian's Book - Test-Driven JavaScriptDevelopment

　　原文地址：http://msdn.microsoft.com/en-us/magazine/gg655487.aspx

　　由于本人水平有限，虽然花费了大量的时间来翻译，错误难免。欢迎大虾批评指正。

原文转自：http://www.ltesting.net