使用JUnit作为验收测试框架

Question

好的,所以我为一家近年来公开采用敏捷实践进行开发的公司工作.我们的单元测试和代码质量正在提高.我们仍在努力的一个领域是在自动验收测试领域找到最适合我们的方法.我们希望利用我们构建良好的用户故事并使用它们以测试驱动的方式驱动代码.这也将为我们提供每个用户故事的验收水平测试,然后我们可以自动化.

到目前为止,我们已经尝试过Fit,Fitnesse和Selenium.每个都有自己的优势,但我们也有它们的真正问题.有了Fit和Fitnesse,我们不禁觉得它们过于复杂,我们在使用它们时遇到了很多技术问题.该公司尚未完全购买这些工具,并不是特别热衷于维护脚本(并且不是桌面风格的忠实粉丝).Selenium非常好,但速度慢,依赖于实时数据和资源.

我们现在正在考虑的一种方法是使用JUnit框架来提供类似的功能.不是使用JUnit仅测试一小部分工作,为什么不使用它来编写测试(使用JUnit框架)来覆盖应用程序的接受级别？即采取一个新的故事("作为一个用户,我希望看到我的政策的基本细节......")并在JUnit中编写一个测试,该测试开始在政策详细信息链接的入口点执行应用程序代码,但涵盖所有代码并且逻辑到存根数据访问层并返回到转发到应用程序中的下一页的点,断言用户应该在该页面上看到什么数据.

在我看来,这具有以下优点:

• 简单(无需额外的框架)
• 零工作与我们的持续集成构建服务器集成(因为它已经处理了我们的JUnit测试)
• 团队中已经存在完整的技能组合(毕竟它只是一个JUnit测试)

缺点是:

• 减少客户参与(尽管他们在编写验收测试的第一个位置上大量参与编写用户故事)
• 也许更难以理解(或理解)JUnit类中的用户故事和接受标准与自由文本规范ala Fit或Fitnesse相比较

所以,我的问题是,你有没有尝试过这种方法？曾经考虑过吗？你的想法是什么？你对这种方法有什么喜欢和不喜欢？最后,如果你能说出你喜欢或不喜欢它们的原因,请仅提及其他框架.

Answer 1

我使用JUnit进行验收测试框架的经验.

我们公司做了一个非常相似的事情,我们从FitNesse开始,然后去了JUnit.我们这样做主要是因为FitNesse已经位于Java之上了,所以切换到JUnit很容易.FitNesse似乎不适合(没有双关语)我们的需求.

以下是我使用JUnit的优点和缺点:

优点:

• JUnit具有很大的灵活性(因为它是Java),因此创建内部域特定语言 [Fowler] 相对容易.可以修改DSL,以便域专家(而不是软件工程师)可以轻松读/写.
• 由于它是JUnit,因此您可以将Eclipse用作IDE,它可以为您提供自动完成,语法检查,调试等.
• 特定于我们的应用程序,我们有一个UI的CORBA接口.Java也可以轻松使用这个CORBA接口.

缺点:

• 人们听到JUnit并思考单元测试.当人们开始将验收测试称为"JUnit测试"时,这会让人感到困惑.
• 为了提供简化的测试环境,您必须花一些时间来扩展框架并开发DSL.

总而言之,如果您愿意花时间将其扩展到您自己的特定于域的测试环境中,JUnit适用于验收测试.否则我想我会在其他地方寻找更开箱即用的东西.

Answer 2

商业和UAT
业务大多数时间迟早会对任何测试工具失去兴趣.毕竟他们是Business而不是测试人员,因此他们不会在编写/维护测试脚本方面做出太多贡献.他们是商业,他们想做生意.从他们的角度来看,测试人员/开发人员/其他IT人员负责为他们提供一定质量的软件.
即使敏捷是您的方式,并且您从业务中获得某种程度的承诺,也不要指望它们在每次冲刺/迭代或任何您拥有的内容时都像测试人员一样.这真的不是他们的工作.
一个题外话:用户验收测试是由用户执行的手动测试,因此他(他们)可以说产品是他(他们)所要求的.
因此,每当功能(或功能集)准备就绪时,为业务做演示,让他们玩它,让他们说是他们需要的.不要强制他们在每次迭代时检查此功能.

现在回到你的验收测试.每当您有客户要做的故事时,请在测试基础架构中为其实施测试.你写它,你运行它,你维护它.使用ADD/BDD/TDD或任何您想要调用的功能测试功能和驱动器开发可能是明智之举.显而易见的是,此测试不会在下一次迭代中对您的回归测试套件做出贡献.

所以我的观点是,Business不会热衷于编写/维护测试,特别是当功能集增长时.不要与之抗争,适应它.让他们在迭代结束时进行(手动)用户验收测试,以获得新功能.为了您自己,为他们想要的功能创建测试.为每个功能创建功能验收测试.让这些测试成为您的回归测试套装.接受这是维护它的责任.

验收测试框架
JUnit,是吗？然后尝试使用WatiJ for web和Abbot for desktop.请记住,那些测试不是简单的单元测试.您想要一些能够测试实际应用程序功能的东西,您希望测试脚本执行特定的场景/业务流程.这意味着您需要编写这些测试,例如编写他们正在测试的应用程序:DRY,KISS,YAGNI,Design Patterns - 一切都适用.最后,它将编写软件,恰好可以测试您编写的其他软件.

这种方法会使这些测试变得庞大而复杂吗？嗯,比单元测试更大,更复杂.但他们不是测试单个单元而是整个应用程序.此外,它们将比您首先编写的应用程序更简单,更小.

你会编写测试框架吗？如果您希望通过这种方法取得成功,那么您将编写测试框架 - 测试类和帮助程序类的集合,这些类具有对应用程序实现的一些了解.但是你不会扩展JUnit.这里的JUnit只是您在框架中使用的一些API.

Answer 3

使用JUnit编写验收测试是完全有效的。JUnit只是一个测试执行框架，无论您实际上是用它编写单元测试，组件测试，集成测试还是验收测试，它都完全无关紧要。正如user1704737所说的那样，拥有可读取的DSL来编写测试很重要。

为了在JUnit中编写测试，我建议您尝试一下JGiven。它是一个轻量级的框架，可以轻松地用纯Java的给定时间标记编写验收测试。它使用JUnit（或TestNG）作为测试执行程序，因此可以轻松地将其集成到现有的测试基础架构中。您还将获得验收测试的HTML报告，可以向他们展示业务以根据要求验证测试。

免责声明：我是JGiven的作者

Answer 4

恕我直言，这不是一个好主意。除了您提到的两个缺点之外，构建一个验收测试框架来处理您可能遇到的各种 Web/UI/glue 场景所需的大量工作又如何呢？您的观点“简单性（不需要额外的框架）”是不正确的，因为您的组织必须投资在 JUnit 之上构建更复杂的框架。它可能比 JUnit 还要多。