单元测试与集成测试＆amp;它的维护

Question

我正在开发一个在并行开发环境中不断增强的Web应用程序（在两个不同的环境中开发两个需求，并在第一个需求发布到生产时将第一个代码库合并到第二个代码库）。

我的问题是关于为应用及其维护进行集成测试和单元测试。

使用模拟进行单元测试使得在并行开发中难以维护测试，并行开发中的集成测试（使用selenium）使得难以在数据库中维护所需的数据（这可能比修复失败的单元测试更容易）

我倾向于集成测试，因为合并代码不会破坏用例，但单元测试用例可能因为期望而合并代码而失败。 该应用程序有点旧，设计不合适用于单元测试和重构代码以及维护单元测试用例变得越来越难。请建议更好的测试方法。

Answer 1

单元测试和集成测试都有它们的位置。 如名称所示，单元测试验证单元的行为是否符合预期。 集成测试确实涵盖了单元测试所涵盖的相同代码。但单元测试可以帮助您更轻松地解决问题。而不是调查未能理解系统的哪个部分负责该问题 - 您有一个失败的单元测试来帮助您找到答案。 进行单元测试的另一个原因是速度。单元测试应该很快。它们不应该依赖于各种系统依赖（你应该使用模拟和存根）。如果您的单元测试具有良好的覆盖率，则可以在开始长时间的测试循环之前快速获得有关系统质量的反馈。

实际上，您通常会采用各种级别的自动化测试：

1. 烟雾测试。这是在最基本的场景中测试系统的各个部分的单元测试。它们通常用作门禁登记入住的一部分，不会检查错误的代码。你需要快速。
2. 回归 - 单元测试。通常是持续集成的一部分。再次，您需要尽可能快地使构建不会花费太长时间。
3. 完全回归+集成测试。这些是需要更长时间运行的更多系统测试。这些通常每天在夜间建造中运行一次，甚至更少（取决于长度）

Answer 2

如果您发现维持某些类型的测试的成本太高，考虑丢弃它们是明智的。我认为集成测试对于QA更重要，如果我只能选择一种类型的测试（单元与集成），那就是我想要的。

但是，首先您可能还需要考虑是否有一种方法可以将您的单元测试考虑在内，以避免出现这些维护问题。当我第一次开始使用模拟时，我花了一段时间才找到合适的平衡点。根据我的经验，我发现最好尽可能多地避免模拟（带有期望）。我确实使用模拟库，主要是为了琐碎的存根而不是更复杂的模拟。如果你有兴趣的话，我前一段时间写了blog post。

Answer 3

关于单元测试问题：

我怀疑你不断重构的单元测试有点太低了。通常，最好通过改变输入来进行更高级别的测试，以执行较低级别的代码。

假设没有不必要的代码，更高级别的测试仍应提供良好的代码覆盖率（如果他们无法访问代码，为什么代码存在？）。

关于功能测试问题：

您可能需要考虑代表性数据样本（或多个）。这样你就可以有一个已知的输入，所以你应该得到可预测的输出。