使用 JUnit 作为验收测试框架

automated-tests java junit acceptance-testing

2022-09-02 09:50:43

好吧，所以我为一家近年来公开采用敏捷实践进行开发的公司工作。我们的单元测试和代码质量正在提高。我们仍在努力的一个领域是在自动化验收测试领域找到最适合我们的东西。我们希望采用我们格式良好的用户故事，并使用这些故事以测试驱动的方式驱动代码。这也将为我们提供每个用户情景的验收级别测试，然后我们可以自动化。

到目前为止，我们已经尝试了Fit，Fitnesse和Selenium。每个都有其优点，但我们也有真正的问题。有了Fit和Fitte，我们不禁觉得它们使事情变得过于复杂，并且我们在使用它们时遇到了许多技术问题。该企业尚未完全购买这些工具，并且并非一直特别热衷于维护脚本（并且不是表格样式的忠实粉丝）。硒真的很好，但速度很慢，依赖于实时数据和资源。

我们现在考虑的一种方法是使用 JUnit 框架来提供类似的功能。与其使用 JUnit 测试一小部分工作单元，为什么不使用它来编写测试（使用 JUnit 框架）来覆盖应用程序的接受级别范围呢？即，采用一个新故事（“作为用户，我希望看到我的策略的基本详细信息...”），并在JUnit中编写一个测试，该测试在策略详细信息链接的入口点开始执行应用程序代码，但涵盖了所有代码和逻辑，一直到存根数据访问层，然后返回到转发到应用程序中的下一页，断言用户应在该页面上看到哪些数据。

在我看来，这具有以下优点：

简单（无需其他框架）
无需努力与我们的持续集成构建服务器集成（因为它已经处理了我们的 JUnit 测试）
团队中已经存在完整的技能（毕竟它只是一个JUnit测试）

缺点是：

减少客户参与（尽管他们首先大量参与编写用户故事，从中编写验收测试）
也许更难理解（或理解）JUnit类中的用户故事和验收标准与自由文本规范ala Fit或Fitite

所以，我的问题是，你有没有试过这种方法？有没有考虑过？你有什么想法？你喜欢和不喜欢这种方法的什么？最后，请仅提及替代框架，如果你能说出为什么你喜欢或不喜欢它们而不是这种方法。

答案 1

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

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

以下是我使用JUnit的优缺点：

优点：

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

缺点：

人们听到JUnit并想到单元测试。当人们开始将验收测试称为“JUnit测试”时，这会令人困惑。
为了提供简化的测试环境，您必须花一些时间来扩展框架并开发DSL。

因此，总而言之，如果您愿意花时间将其扩展到您自己的特定于域的测试环境中，JUnit对于验收测试来说效果很好。否则我想我会在其他地方寻找更多开箱即用的东西。

答案 2

大多数时候，Business和UAT
Business迟早会对任何测试工具失去兴趣。毕竟，他们是业务而不是测试人员，因此他们不会在编写/维护测试脚本方面投入太多。他们是生意，他们想做生意。从他们的角度来看，测试人员/开发人员/其他IT人员负责为他们提供一定质量的软件。
即使敏捷是你的方式，并且你从业务部门获得了一定程度的承诺，也不要指望他们在每次冲刺/迭代或你拥有的任何东西上都表现得像测试人员一样。这真的不是他们的工作。
一个题外话：用户验收测试是由用户执行的手动测试，所以他（他们）可以说是他（他们）要求的产品。
因此，每当功能（或功能集）准备就绪时，为业务做演示，让他们玩一玩，让他们说这是他们需要的。不要强迫他们在每次迭代时检查此功能。

现在回到验收测试。每当有来自客户端的故事要做时，请在测试基础结构中为其实施测试。你写它，你运行它，你维护它。使用ADD / BDD / TDD或任何您想要调用它的功能和驱动开发的测试可能是明智的。很明显，此测试在下一次迭代中对回归测试套件的贡献更大。

所以我的观点是，企业不会热衷于编写/维护测试，特别是当功能集增长时。不要与它斗争，适应它。让他们在新功能的迭代结束时只执行（手动）用户验收测试。为了您自己的利益，为他们想要的功能创建测试。为每个功能创建功能验收测试。让这些测试成为你的回归测试套装。接受 t 是你维护它的责任。

验收测试框架
JUnit，对吧？然后尝试使用Web的WatiJ和桌面的Abbot。请记住，这些测试不会是简单的单元测试。你想要一些东西来测试实际应用程序的功能，你想要测试脚本来执行特定的场景/业务流程。这意味着您需要编写这些测试，就像编写他们正在测试的应用程序一样：DRY，KISS，YAGNI，Design Patterns - 一切都适用。最后，它将是编写软件，只是碰巧测试您编写的其他软件。

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

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