事实之后，Pro和Con的unit testing
我有一个大约27K线大复杂的应用程序。 它本质上是一个驱动multithreading处理引擎的驱动程序，没有太多的脱离，它已经部分testing，因为它已经build成，某些组件。
我有问题，事后可以做unit testing的亲和做什么，可以这么说呢，是在执行之后。 很明显，传统的testing需要2-3个多月的时间来testing每一个方面，这一切都需要工作，而这个时间是不可能的。
过去，我已经做了相当多的unit testing，但一般都是在桌面自动化或LOB应用程序上进行的，这很简单。 该应用程序本身是内部高度组件化，真正的接口驱动。 我还没有决定使用什么特定的框架。 任何意见，将不胜感激。
什么说你。
根据“手动testing”出现的错误数量，您可以简单地进行testing驱动的错误修复 ，根据我的经验，这比通过编写“验后”unit testing简单地提高代码覆盖率要有效得多。
（这不是说后来写unit testing是一个坏主意，只是TDD几乎总是一个更好的主意 。）
我认为unit testing现有的代码有几个优点
- 回归pipe理
- 更好地理解代码。 testing它将揭示你没有预料到的情况，并将帮助定义代码的行为
- 它会指出代码中的devise缺陷，因为你试图testing定义不当的方法。
但是我认为考虑unit testing代码的缺点更有意思。 AFAIK，没有缺点。 所有花在testing上的时间都会在最短的时间周期内为自己付出代价。
unit testing代码有很多原因。 事后我主张unit testing的主要原因很简单。 你的代码坏了，你还不知道。
软件中有一个非常简单的规则。 如果代码没有经过testing，那就坏了。 这可能一开始并不明显，但是当你开始testing时，你会发现错误。 这取决于你自己多less关心find这些错误。
除此之外，unit testing还有其他几个重要的好处，
- 回归testing将变得更简单
- 其他开发人员，知识较less，不能打破你想要的行为
- testing是自我logging的一种forms
- 可以减less将来修改时间（不再需要手动testing？，减less错误？）
名单可以继续下去。 唯一的缺点是编写这些testing需要花费时间。 我相信这个缺点总是会被你debuggingunit testing时发现的问题的时间所抵消！
以下是我的一些想法：
优点：
- 随着时间的推移，devise不断演变，节省了时间，无需testing已经被删除的方法。 剩下的是真正需要testing的东西。
- 通过添加testing，这允许一个机会来审查应用程序中的所有方面，并确定现在可以添加一个工作原型的其他优化。
缺点：
- 大量的时间投入来获得testing写入，新的function可能会延迟一段时间来生成所有的testing。
- 错误可能已经被引入，testing将发现可能导致这个比最初计划更长的时间。
主要的一点是，添加unit testing可以重构并在应用程序中join更多的优化。
我认为，“事后”testing的最大缺点之一是你可能会有更难testing的时间。 如果你没有testing编写代码，你通常没有考虑到可testing性，最终编写难以testing的代码。
但是，当您花费额外的时间编写testing并更改代码以获得更好的可testing性之后，一旦您不需要大量时间进行debugging并检查一切是否正常， 就会更有信心进行更改 。
最后，您可能会发现以前没有捕获到的新bug，并花费一些时间修复它。 但是，嘿，这就是testing的目的=）
Pro 事后unit testing：
- 获取你可以信任的文档。
- 提高对代码的理解。
- 推动重构并改进代码本身。
- 修复潜伏在代码中的错误。
Con 事后unit testing：
- 浪费时间修复你可以忍受的错误 。 （如果你写了27KLOC，我们希望它能做些什么，对吧？）
- 花时间理解并重构你不需要理解的代码。
- 失去可能进入下一个项目的时间。
未经质疑的问题是这个代码长期以来对你的组织来说有多重要？ 这个问题的答案决定了你应该投资多less。 我有很多（成功的）竞争对手，他们的代码的主要目的是获取数字来评估一些新技术或想法。 一旦有了这些数字，代码就没有什么边际价值了。 他们（正确）非常仔细地testing，以确保数字是有意义的。 之后，如果有五十个不影响数字的开放式错误，他们不在乎。 为什么他们呢？ 代码已经达到了目的。
如果您正在进行任何重构，那么这些testing将帮助您检测出现在过程中的任何错误。
“事后”unit testing仍然是有价值的，在开发过程中提供了大部分与unit testing相同的优点。
这就是说，我发现在事实之后testing更多的工作（如果你想获得相同的testing水平）。 这仍然是有价值的，仍然值得。
就个人而言，当我试图在有限的时间内处理某些事情时，我尽可能地集中我的testing工作。 任何时候你修复一个错误，添加testing，以防止在未来。 任何时候你要重构，试着做足够的testing来确信你不会破坏某些东西。
添加unit testing的唯一好处是它需要一些开发时间。 就个人而言，我发现在testing中花费的时间远远超过了维护时间，但这是您自己需要确定的。
unit testing仍然是有用的。 查看http://en.wikipedia.org/wiki/Unit_testing获取完整的列表和解释。;
您将获得的主要好处是文档，使更改变得更容易，并简化了未来的集成。
除了时间之外，添加unit testing确实没有任何成本。 意识到你花时间增加unit testing的时间会减less你需要花费在其他开发领域的时间，至less是相同的数量，而且可能更多。
unit testing并不能certificate一个系统的工作。 certificate每个单位都是独立的单位。 这并不能certificate这个综合系统是可行的
“事实之后”的unit testing对于两件事情是有用的 – 找出迄今为止错过的错误，并且不会发现使用任何其他types的testing（特别是对于罕见的情况 – 特别是可能发生的大量罕见情况单位为任何真实世界的系统），并在维护期间作为回归testing。
这两种方法都不会对你的情况有很大的帮助 – 你需要以任何方式进行其他forms的testing。 如果你没有时间做你需要做的事情，承担更多的工作是不可能的。
也就是说，如果没有进行unit testing，我保证当客户开始使用代码的时候会有令人讨厌的惊喜。 这就是所有这些罕见的情况 – 其中有很多，其中一些很快就会发生。 黑盒testing人员倾向于进入习惯性模式，这意味着他们只能testing这么多罕见的情况 – 而且他们无法知道特定单位有哪些罕见情况，以及如何触发它们。 更多用户意味着更多的使用模式的变化。
我和那些说unit testing应该写作编程过程的一部分的人一样 – 程序员的职责之一。 通常情况下，代码的写入速度会更快 ，因为随着时间的推移，您可以获得越来越less的复杂错误，当您熟悉具有错误的代码时，您会发现它们。
如果开发“完成”，我会说unit testing没有太多的意义。
这是这些困难的价值判断types的问题之一。
我主要同意Epaga的观点，那就是在修正bug（也许是在引入一些额外的testing）时编写新的testing是一个好方法。
我会再补充两点意见：
- 在进行大的改动之前对单元进行退黑盒testing可能是一个好主意
- 一致性testing不是unit testing，但是某些types的程序适合于简单生成一致性testing。 这可能是确保你不会破坏事物的一种方法。
