我听说为您的应用程序编写（编码）单元测试有效地使项目所需的开发时间加倍。这是真的吗，特别是初学者？
还有一些后续问题（布朗尼点）： 如果你正在做一个你完成后交接的客户项目，是否值得花时间和精力进行单元测试？
答案 0 :(得分：19)
我想说，两倍的时间是一个公平的估计，是的，单位测试 总是 值得花时间和精力。
但是我认为单元测试所花费的时间远远少于因缺乏单元测试而导致调试和修复错误所需的时间。
答案 1 :(得分：9)
为您的单元测试编写（编码） 应用程序有效地使用了两倍 开发时间 项目。
如果只计算输入代码的时间，编写测试肯定比根本不写测试慢。但是，如果你考虑到在没有测试安全网的情况下破坏现有功能 - 调试修复的时间，那么除了琐碎的项目之外，其他任何好处都会超过成本。测试可以帮助您设计（TDD）+防御（回归）+文档（规范）。
这是真的吗，尤其如此 对于初学者？
这取决于。用Beck（我想）来解释一下，如果你是一个笨蛋，工具/方法对你没用，如果你是一个编码 - 上帝，你可能不需要它们。然而对于我们中间的大多数人来说，它会有所帮助。当你在那个频谱上向右移动时，事情成为你的第二天性，你要“看到”什么时候到来，时间开始减少（尽管不是0）。为了避免犯错误，找一个已经去过那里的人（从邮件列表中获取帮助或者暂时聘请一位好教练）
还有一些后续问题（布朗尼点）：如果你正在做一个客户项目 你完成后放手，是否值得花时间和精力进行单元测试？
即使下一个团队放弃了测试套件，我仍然会这样做，以提高我的工作效率，减少创建和追逐bug的时间。
答案 2 :(得分：6)
如果您使用TDD，则不会因为：
您实际上是先编写测试。这本身就是一个很大的节省时间，因为你已经奠定了你要做的事情。您还知道何时停止编码。 （当测试通过时）
当您实际编写代码时，它会尽可能地小。通过测试后，您可以停止编码，只要测试仍在通过，您就可以更自信地进行编码。
然后为边缘情况编写测试（如果需要）并检查是否存在问题。
我已经这样做了，发现这实际上减少了开发时间 - 因为在你开始编写实际代码之前，你已经考虑过你想要做什么，而且你知道什么时候你已经完成了它实际上有效。
答案 3 :(得分：4)
单元测试还用于记录代码库，目的是如何使用/调用特定的类/方法。
答案 4 :(得分：3)
我想这取决于你所定位的测试覆盖范围
如果您打算遵循TDD的真实定义，其中每行代码都通过单元测试用例进行测试 - 您可能正在寻找巨大的努力
但它不一定是那个
你可以找到自己的平衡......
根据我的经验 - 我没有发现这会使时间加倍 - 虽然它确实增加了一个因素（20-25％？）
我的意思是 - 即使您没有单元测试用例 - 您仍然可以手动进行单元测试 - 对吧？
在整个项目期间，你会发现在单元测试用例上花费的时间很容易被忽略
对于客户项目 - 恕我直言，是的。他们希望能够体会到这一努力
答案 5 :(得分：2)
我认为编写自动化单元测试的时间因您的语言和开发方式而异。例如，以非常程序化的方式编写C＃会导致难以开发测试。但是，如果采用不同的方法，比如使用一些模拟和IOC框架，可以大大减少单元测试时间。
答案 6 :(得分：2)
关于增加时间的话题，因为你提到你是初学者：你越早找到适合你需求的单元测试套件就越好。您还没有提到您正在使用的语言，但如果不支持反射（例如C，C ++），那么设置单元测试工具通常需要更长的时间，因为您必须实例化TestSuite和测试，你必须注册测试等等。当你想要做的只是运行几个测试时，这些都是要学习的东西！
另一方面，如果你正在使用像Python这样更具动态性的语言，你可以通过制作一些testXXX方法，几乎不需要任何单元测试知识来设置单元测试。 unittest模块。
关于第二个问题，请将自己置于客户的角度 - 您不想听到您购买的产品已经过彻底测试吗？他们（可能）喜欢数字！告诉他们你已经设置了自动测试，有超过500个单独的测试运行，超过80％的代码已经过这样的测试 - 好吧，只告诉他们真相，但你明白了。它增加了代码可信度方面的巨大价值，坦率地说，我宁愿与能够证明他们知道已经过测试的内容和可能是什么样的内容的人做生意，而不是仅仅是那些人递给我一些东西说“已经完成了。”
答案 7 :(得分：2)
对于我的编程，我倾向于只测试那些我无法直观地看到的代码部分，并且知道它会起作用（有些人认为这是不够的，但这既不在这里也不在那里）。
我已经用这种方式进行了很长时间的编程，并且我使用这些测试来帮助我编写代码。鉴于此，编写测试的时间基本上没有增加我的整体开发时间。如果我跳过编写我所做的测试，它“可能”可以节省我整个时间的10％，如果那样的话。
当我第一次开始使用自动化测试时，我会说编写代码的总时间加倍是一个合理的估计。但是，随着时间的推移，我已经到了我不在的地方（立即加入）。老实说，这是你习惯的东西，它成为你设计代码的一部分。
编辑：我想补充一点，有时候编写测试代码仍会为我的编码增加相当多的时间，有时甚至超过两倍。话虽如此，那些时间很少而且很远，因为我倾向于避免代码这样做......这对我来说是一种代码味道。
答案 8 :(得分：1)
您正在测试的内容将决定需要多长时间。例如，使用MS的数据库单元测试框架为TSQL编写单元测试比编写存储过程花费的时间要长得多，因为这是一个非常手动的过程来准备测试。
但是，如果我将Eclipse或VS2008用于Java或C＃类，并且我只是告诉它创建测试，那么执行测试的速度非常快，因为很多繁重的工作都是为我完成的。
它总是值得的，因为它有助于减少一些可能的错误，但更重要的是，当复制错误时，你最终还是会编写这些测试，如果你不设计你的要进行单元测试的类然后需要重构，这可能会引入新的错误，以便修复报告的错误。
重要的是你会发现你的功能是不可测试的，所以你最终会进行重构，这样你才能进行合理的单元测试。
例如，如果您有一个从数据库中选择的函数，那么在结果上做业务逻辑，您如何正确地测试它？它应该是两个独立的函数，一个控制器调用获取数据，然后调用来执行业务逻辑，所以你将有三个测试，但是，当你有一个单独的测试时，控制器可以转到数据库的模拟测试数据库层。
答案 9 :(得分：1)
如果您对单元测试非常认真，我会推荐The art of unit testing本书Roy Osherove。
答案 10 :(得分：-1)
取决于您获得的好处。传统的网络应用程序完全浪费时间 - 客户会更多地了解乱搞ui，而不是编码慢慢破坏数据。