我的情况,作为一些背景:
我正在编写一个小型javascript库,它使用window.requestAnimationFrame
来执行动画循环。因为该功能尚未在浏览器中标准化,所以在库内部它会在闭包中创建一个polyfill-ish函数。
var requestAnim = window.requestAnimationFrame
|| window.webkitRequestAnimationFrame
|| ...
|| function () { ... };
这里的问题是,这使我现在很难测试这段代码。以前,当它使用setTimeout
时,我会在测试中覆盖该全局函数,以模拟同步传递的多个帧。
无论如何,到了问题的关键点:
现在,似乎我的选择是让我的一些代码未经测试,或者为库添加无关的功能,其唯一目的是使其更容易测试。这些选项对我来说都不是很好。
不要过多担心我的具体案例,一般,在这种情况下你应该怎么做?
答案 0 :(得分:4)
是的,没关系。
我们不会为了测试而编写测试。测试是对这样一个事实的肯定:我们没有足够的能力在没有安全检查的情况下完美地编写和维护代码。所有测试代码都有一个目的,只有一个:制作更好的产品。无论它位于/ test文件夹还是/ src文件夹中,都是如此。因此,认为“在生产中从未调用过它是错误的,因此将它放入/ src是错误的!”
可以肯定的是,还需要做出其他权衡,例如:大小(在嵌入式产品中,尝试一切可以保持/ src文件夹很小很有意义)。但这与完全不同的原因不仅仅是“它与测试相关”。
答案 1 :(得分:1)
我想说添加测试代码是好的(除非你正在测试一些微优化)。正如基利安所说,没有人是完美的;这就是我们首先进行测试的原因。
我+ 1d Kilian的答案,但我也想添加自己的想法:
一般情况下,哪些情况会出现您无法(轻松)测试的代码?这是仅在条件下运行的代码,您无法在测试机器上重新创建?也许更容易设置一个变量来决定是否应运行此代码,然后您可以设置断点并在调试时更改此变量(在您的JavaScript情况下,使用Firebug或Chrome的开发人员工具?)
或者,就像你说的那样,添加一些测试代码 - 一组标志可能在脚本的顶部,以保持整洁?然后你的if语句就像
if(shouldRunThisCode || isTestingThisCode) {
doThisCode();
}
简而言之:当然,为了测试而添加代码是可以的。我想不出任何测试代码需要添加大量代码的场景。如果代码被实现并且打算在某些条件下在某些条件下运行,那么测试就永远不会太难。
答案 2 :(得分:0)
一般来说,难以测试的代码编写得很糟糕。1找到测试困难告诉你的设计问题并修复它们比添加代码“只是为了简化测试”更为优秀。 。有时我们会这样做,因为我们认为设计问题太难解决 - 但它应该是第二选择。在你的情况下,听起来你所暴露的糟糕设计是在你无法控制的库中。在这种情况下,添加代码“只是为了使测试更容易”可能是最好的选择;你不太可能对外部库有足够的控制来改进它的设计。