我最终参加的大多数演出要么很少或没有单元测试。通常,被描述为单元测试的内容实际上是集成测试,并且很少从开发人员的机器上运行。我通常通过宣传两者之间的区别来开始我的布道,并尝试让人们编写非常集中的单元测试并将集成测试留到以后,即当有足够多的人编写单元测试时,我们可以“继续”编写集成测试。验收或系统级测试通常由开发人员手动处理,然后由 QA 部门处理。
我的问题是,在敏捷环境之外工作时,您在单元、集成和验收测试中投入了多少精力,您认为最大的价值是什么?
我最终参加的大多数演出要么很少或没有单元测试。通常,被描述为单元测试的内容实际上是集成测试,并且很少从开发人员的机器上运行。我通常通过宣传两者之间的区别来开始我的布道,并尝试让人们编写非常集中的单元测试并将集成测试留到以后,即当有足够多的人编写单元测试时,我们可以“继续”编写集成测试。验收或系统级测试通常由开发人员手动处理,然后由 QA 部门处理。
我的问题是,在敏捷环境之外工作时,您在单元、集成和验收测试中投入了多少精力,您认为最大的价值是什么?
我尝试从一开始就进行单元测试。我不是世界上最大的 TDD 粉丝,但我真的很喜欢单元测试。我不认为某些魔法仙女会确保集成测试能够顺利通过,因为所有单元测试都有效,但它已经非常接近了。
至于验收测试,在我看到单元测试通过(或失败,如果它们应该失败)之前,我什至不会看一些东西。我想不出很多我会接受完全缺乏单元测试的情况。如果应用程序中的某些核心库更新了怎么办?
许多人会争辩说单元测试是以开发人员为中心的,他们是正确的。然而,缺乏单元测试本身就是一个指标......尤其是如果做验收测试的人恰好是开发人员:)
编辑:
集成测试对我来说也很重要。我们通常按照非常严格的规范构建东西......当集成测试失败(在之前通过之后),它是范围蔓延的一个强有力的指标。发生这种情况时,需要有人在修复它之前发出一些声音。
很多时候,对这个问题的回答变得极端。就像你应该有几乎 100% 的覆盖率或者单元测试是愚蠢的......
我相信你必须找到平衡。
在合理怀疑类逻辑可能失败的情况下使用单元测试。必须在隔离类上进行单元测试,因此这意味着您可能需要模拟该类使用的服务。这样你就可以安全地执行重构,因为单元测试将确保该类仍然按预期工作。
集成测试对于确保您的应用程序完全正常工作是必要的。您可以进行许多单元测试,但这并不意味着您的应用程序可以正常工作。
关于验收测试,我完全同意你的看法。在(冲刺)结束时进行,部分必须手动完成。
我听说单元测试就像测试墙上的单个砖块,而功能/集成测试就像测试整面墙的稳定性。
单元测试对于开发人员来说是必要的,以确保这些类正在做他们应该做的事情。
功能/集成测试是必要的,以确保您没有错过实际提供某些功能的“大图”目标。
所以恕我直言,两者都是绝对必要的,从投资回报率的角度来看,将其中任何一个都排除在外是个坏主意。
我认为你不能混淆它。您描述的每个测试都有不同的目标。
单元测试是针对开发人员的。他们在模块实现之前或并行编写单元测试,以确保其正常工作或满足所有接口和要求。
在测试中心开发之后进行集成测试。在开发过程中,您不会像在单元测试中那样测试单个模块。集成测试涵盖了几个模块之间的交互。
验收测试通常涉及客户自己检查是否满足所有要求以及是否按规定实施功能。