我被赋予了为大型现有软件项目的质量保证体系建议设计的任务。这几天我一直在阅读关于单元测试和测试驱动开发的内容，他们所宣称的概念对我来说似乎非常好。他们似乎也是“行业标准的良好编码实践”，这正是我想要的。
无论如何，我已经把所有这些东西浸入水中，但我不知道如何开始设计这些测试。我的经理的主要目标是测试新的开发代码产生与现有生产代码相同的结果。这种级别的粒度对我来说似乎非常好，但似乎我一直在阅读的有关单元测试和TDD的文章都鼓励更精细的粒度级别（如每种方法的多次测试）。
有许多开发人员同时在这个项目上工作，并且实现高水平的单元测试粒度将是一场噩梦。此外，单元测试的实际好处将在那时减少。
所以我想我想知道的是如何确定需要进行哪些测试。我认为项目的每个重要组成部分的输入/输出测试都是一个很好的基础，但我对如何开发更深入但不太深入的单元测试没有最模糊的想法。如果有一些一般规则，我会有兴趣听取它们。
此外，任何有关在庞大的现有软件项目中实施TDD理念的一般反馈也将受到赞赏。谢谢！
答案 0 :(得分：2)
单元测试和TDD都是有价值的实践，但它们需要被开发人员采用。正如你所说，他们正在编码，不一定是测试，实践。 TDD是一个设计过程，在编写代码之后，您无法通过测试来驱动代码的设计。
单元测试确实应该为每个方法进行多次测试。需要进行许多测试来表达他们正在测试的功能的要求。
如果您必须仅将其视为QA角色，那么请考虑使用功能测试或集成测试来测试应用程序的行为并自动执行这些测试。不幸的是，这不会是行为驱动设计，因为你要描述这些行为对他们驱动应用程序的设计来说太迟了，但BDD中使用的许多工具可能仍然对你有用。
如果这是一个选项我认为你真的想让你的开发人员参与编写测试第一代码。让他们负责生成和验证他们的代码在功能上是否正确，并允许您的QA部门专注于验证所产生的功能实际上是否带来了良好的用户体验。此外，编写测试需要编写可测试的代码。如果没有测试，编写难以单独测试的代码就太容易了。
无论您最终做什么，请查看Feathers的“使用遗留代码”，了解在您的应用程序中查找接缝的策略，您可以在其中引入测试和实践，以确保您不会对应用程序的行为进行意外更改。不幸的是，我认为你会发现在编写代码之后，而不是之前或开发代码时，测试代码的成本会高得多。
编辑：那应该是“working effectively with legacy code”
答案 1 :(得分：1)
我的经验表明，最简单的方法是使用最粗的粒度级别。首先尝试自动化功能测试 - 看看BDD。功能（至少在理论上）应该对每个人都清楚，因此更容易定义接受标准。它也是那种具有最可感知价值的测试。它处理系统客户（或最终用户）感知的质量。
当您进入最精细的粒度级别（集成测试，单元测试）时，您主要关注的是产品的内在质量。因此，您将拥有更好的设计组件，这将对软件的易于演变和维护产生影响。在大多数情况下，这只能被开发人员察觉（根据我的经验，而不是所有人）。因此，要让您的经理和客户相信它的好处将更难。另外，根据我的经验，通过这种类型的测试开始实施测试文化更加困难。
所以我的建议是，首先要采用最高级别的粒度，随着您的团队获得动力，开始进入较低级别。另一个建议是，一步一步走。不要从为所有系统创建测试的目标开始。从最关键的功能，最关键的组件开始，然后慢慢填补系统的所有空白。