jQuery 范式是反对单元测试还是补充它？
是的，我知道 QUnit，但使用 jQuery 范式就是用更少的代码更快地完成工作，这是否与 TDD 范式有些相反？或者它以某种方式补充它？
Yes, I am aware of QUnit, but with the jQuery Paradigm all about getting things done faster with less code, and is this some how opposed to a TDD Paradigm? Or does it complement it somehow?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
JQuery 本身具有很好的代码覆盖率，核心开发团队使用 FireUnit 和 QUnit 等工具。当您扩展库时，编写自己的插件和方法 TDD 变得更加重要。您花费多少时间进行跨浏览器测试和验证您所做的每项更改？通过创建单元测试，您可以放心地编写代码，只需运行测试套件即可立即获得结果，而不必启动所有浏览器并测试您的更改。通过在每个视图分钟运行一个测试套件，如果出现故障，您最多只会损失几分钟的时间，而如果出现故障，您最多只会损失几个小时甚至几天的时间。此外，如果您使用 WatiN 或类似的东西在 CI 构建中设置了测试工具，您甚至不需要启动浏览器，它是完全自动化的。所以你是对的，编写测试确实需要时间，但这是“现在付款或稍后付款”的情况，而且“现在付款”的投资要便宜得多。
JQuery itself has great code coverage and the core dev team uses tools like FireUnit and QUnit. As you extend the library writing your own plugins and methods TDD is even MORE critical. How much time do you spend cross-browser testing and verifying each and every change you make? By creating Unit Tests you can write code in confidence and simply run your test suite and get instant results instead of having to fire up all your browsers and test your changes. By running a test suite every view minutes you at most only lose a few minutes of time if something fails versus losing hours or even days if something breaks. Furthermore, if you have your testing harness set up in a CI build using WatiN or something similar you don't even need to launch browsers it's completely automated. So you are correct, writing tests does take time but it's a "pay now or pay later" scenario, and it's a much cheaper investment to "pay now".