事后单元测试的利弊
我有一个比较大的复杂的应用程序，大约27k行。它本质上是一个规则驱动的多线程处理引擎，不会泄露太多，它在构建时已经过部分测试，某些组件。
我的问题是，在实现单元测试之后，可以说，进行单元测试的利弊是什么。很明显，传统的测试将需要2-3个多月的时间来测试每个方面，并且所有这些都需要工作，而时间确实是不可用的。
我在过去做过相当多的单元测试，但通常都是在桌面自动化或LOB应用程序上进行的，它们相当简单。这个应用本身就是高度组件化的，真正的界面驱动。我还没有决定使用哪种特定的框架。任何建议都将不胜感激。
你说呢。
回答 12
Stack Overflow用户
发布于 2010-03-23 15:30:24
根据“手动测试”出现了多少错误，您可以简单地进行测试驱动的错误修复，在我的经验中，这比简单地通过编写“事后”单元测试来提高代码覆盖率要有效得多。
(这并不是说事后编写单元测试是一个坏主意，只是测试驱动开发几乎总是一个更好的想法。)
Stack Overflow用户
发布于 2010-03-23 00:55:02
我认为对现有代码进行单元测试有几个优点
了解management
- Better的
- 回归的代码。Testing it 将揭示您没有预料到的情况，并将有助于定义代码的行为
- 它将指出代码中的设计缺陷，因为您正在艰难地测试定义不佳的方法。
但我认为考虑单元测试代码的缺点会更有趣。阿费克，没有什么坏处。花在添加测试上的所有时间都会得到回报，即使在最短的时间周期之外的所有事情上也是如此。
Stack Overflow用户
发布于 2010-03-23 01:10:06
对代码进行单元测试有很多原因。我提倡事后进行单元测试的主要原因很简单。你的代码坏了，你只是还不知道而已。
在软件中有一个非常简单的规则。如果代码没有经过测试，它就会崩溃。这一点一开始可能不是很明显，但当你开始测试时，你的会发现bug。这是由你决定你有多关心找到这些bug。
除此之外，单元测试还有其他几个重要的好处，
- 回归测试将变得更简单
- 其他开发人员，他们知识较少，不能破坏您想要的行为
- 测试是一种形式的自我测试减少未来修改的时间(无需更多手动测试？，更少错误？)
这份清单可以继续下去。唯一真正的缺点是编写这些测试所需的时间。我相信，当你调试你在单元测试时可能发现的问题时，这个缺点总是会被抵消的！
https://stackoverflow.com/questions/2494102
复制相似问题
腾讯云开发者
