我听说为您的应用程序编写(编码)单元测试有效地使项目所需的开发时间加倍.这是真的吗,特别是初学者？
还有一些后续问题(布朗尼点):如果你正在做一个你完成时交出的客户项目,是否值得花时间和精力进行单元测试？
And*_*are 20
我想说,两倍的时间是一个公平的估计,是的,单元测试总是值得花时间和精力.
但是,我认为单元测试所花费的时间远远少于因缺乏单元测试而导致调试和修复错误所需的时间.
为您的应用程序编写(编码)单元测试有效地使项目所需的开发时间加倍.
如果只计算输入代码的时间,编写测试肯定比完全没有编写任何测试要慢.但是,如果你考虑到在没有测试安全网的情况下破坏现有功能 - 调试修复的时间,那么除了琐碎的项目之外,其他任何好处都会超过成本.测试可以帮助您设计(TDD)+防御(回归)+文档(规范).
这是真的吗,特别是初学者？
这取决于.用Beck(我想)来解释一下,如果你是一个笨蛋,工具/方法对你不会有帮助,如果你是一个编码 - 上帝,你可能不需要它们.然而对于我们中间的大多数人来说,它会有所帮助.当你在那个频谱上向右移动时,事情成为你的第二天性,你要"看到"什么时候到来,时间开始减少(尽管不是0).为了避免犯错误,找一个已经去过那里的人(从邮件列表中获取帮助或者在一段时间内聘请一位好教练)
还有一些后续问题(布朗尼点):如果你正在做一个你完成时交出的客户项目,是否值得花时间和精力进行单元测试？
即使下一个团队放弃了测试套件,我仍然会这样做,以提高我的工作效率,减少创建和追逐bug的时间.
如果您使用TDD,则不会:
你实际上是先编写测试.这本身就是一个很大的节省时间,因为你已经奠定了你要做的事情.您还知道何时停止编码.(当测试通过时)
当你实际编写代码时,它会尽可能小.通过测试后,您可以停止编码,只要测试仍在通过,您就可以更自信地进行编码.
然后为边缘情况编写测试(如果需要)并检查是否存在问题.
我已经做到了这一点,发现这实际上减少了开发时间 - 因为在你开始编写实际代码之前,你已经考虑过你想要做什么,并且你知道什么时候你已经完成它实际上有效.