问题描述
|
我目前正在使用现有系统进行咨询，我怀疑正确的下一步是添加单元测试，原因是正在发生的异常类型（空指针，空列表，无效的返回数据）。但是，在应用程序中具有“个人投资”的员工坚持进行集成测试，即使所报告的问题与特定用例失败无关。在这种情况下，从单元测试或集成测试开始更好吗？
解决方法
通常，很难对未经测试的代码库进行改造以进行单元测试。这将具有高度的耦合性，并且运行单元测试将比获得的回报花费更多的时间。我建议以下内容：
至少获得一份由Michael Feathers撰写的“有效地使用旧版代码”，并与团队成员一起阅读。它处理这个确切的问题。
对所有新编写的代码执行严格的单元测试（最好是TDD）策略。这将确保新代码不会成为旧代码，并且对新代码进行测试将推动重构旧代码以实现可测试性。
如果有时间（您可能没有），请在系统的关键路径上编写一些关键的集成测试。这是一个很好的检查，以确保您在步骤2中执行的重构没有破坏核心功能。
,集成测试扮演着重要的角色，但是代码测试的核心是单元测试。
开始时，您可能只被迫进行集成测试。原因是您的代码库耦合非常紧密（因为没有单元测试，这只是一个疯狂的猜测）。紧密耦合意味着您必须先创建许多相关对象才能创建要测试的对象实例。这使得所有测试都可以按照定义进行集成测试。编写这些集成测试非常重要，因为这些测试应该用作您的错误查找/重构工作的基准。
编写记录该错误的测试。
修复该错误，使所有创建的单元测试均为绿色。
现在该当个好孩子了（把营地/代码按输入时的顺序排列）：编写测试以记录包含该错误的类的功能。
作为童军努力的一部分，您开始使班级与其他人脱钩。依赖注入是这里的工具。认为不要在其他类内部构造其他类-应该将它们作为接口注入。
最后，在解耦了类之后，您也可以解耦测试。现在，当您注入接口而不是在测试的类中创建具体实例时，您可以创建桩/模拟。突然，您的测试已成为单元测试！
您也可以创建集成测试，在其中注入具体的类而不是存根和模拟。只记得要使它们远离单元测试。最好在另一个组件中。单元测试应该能够一直运行，并且运行得非常快，不要因为缓慢的集成测试而降低了它们的速度。
,问题的答案取决于提出问题的背景。如果您希望使用现有的代码库，并且正在考虑重写或替换大部分代码，则围绕希望重写或替换的组件设计一套全面的集成测试将更有价值。另一方面，如果您对需要支持和维护的现有系统负责，则可能首先要从单元测试开始，以确保您更侧重的更改不会引入错误。
我换种说法。如果有人寄给您一辆旧车，请看一看。如果您要立即更换所有组件，则不必费心测试喷油器的微小性能特征。另一方面，如果您要按原样维护汽车，则继续并针对要修复的组件编写目标单元测试。
一般规则，没有单元测试的代码很脆弱，没有集成的系统很脆弱。如果您将专注于低级代码更改，请首先编写单元测试。如果您将专注于系统级更改，请编写集成测试。
另外，请确保忽略在此类网站上阅读的所有内容。这里没有人知道您的项目的细节。
,在集成测试和单元测试之间进行选择是非常主观的。它取决于代码库的各种度量标准，尤其是类的内聚和耦合。
我将提供的一般性建议是，如果类是松散耦合的，那么测试设置将消耗更少的时间，因此，开始编写单元测试会更容易（尤其是针对代码库中更关键的类） 。
另一方面，在高度耦合的情况下，您最好针对更关键的代码路径编写集成测试，特别是从松散耦合的类（并且驻留在执行堆栈中更高级别的类）开始。同时，必须尝试重构涉及的类以减少耦合（同时将集成测试用作安全网）。