使用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），因此创建内部Domain Specific Language [Fowler]相对容易。可以修改DSL，以便域专家（而不是软件工程师）可以轻松读/写。
• 由于它是JUnit，您可以将Eclipse用作IDE，它可以自动完成，语法检查，调试等。
• 特定于我们的应用程序，我们有一个UI的CORBA接口。 Java也可以轻松使用这个CORBA接口。

缺点：

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

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

Answer 2

Answer 3

使用JUnit编写验收测试是完全有效的。 JUnit只是一个测试执行框架，无论你是用它来编写单元测试，组件测试，集成测试还是验收测试都完全无关紧要。 正如user1704737已经说过，你有一个可读的DSL来编写你的测试很重要。

要在JUnit中编写测试，我建议尝试JGiven。它是一个轻量级框架，可以轻松地在普通Java中以给定时间表示法编写验收测试。它使用JUnit（或TestNG）作为测试执行器，因此可以轻松地将其集成到现有的测试基础架构中。您还可以获得验证测试的HTML报告，您可以向企业展示根据需求验证测试的结果。

免责声明：我是JGiven的作者

Answer 4

如果你遵循这条道路，可以提出一些建议：

• 将您的验收测试放在另一个项目中，因为它们可能会比您通常的测试运行得更慢且依赖性更高
• 创建构建器（可能使用fluent interface）在测试装置中设置模型，因为您会发现为测试设置所需的对象将是最难以维护的部分。
• 看一下Groovy和Spock Framework：它与JUnit兼容，但为您提供了一个很好的DSL，让您的测试可读。

Answer 5

尝试使用robotframework（www.robotframework.org），我已经使用它多年了，来自赫尔辛基的Pekka Klarck开发了它（诺基亚西门子通信从一开始就支持它，现在它也是开源的）。

robotframework使用表格格式测试用例，支持HTML，CSV或纯文本（用特定语法编写）。它有一个库机制，支持导入Selenium函数。您可以使用Python或Java为robotframework编写库。

对于JUnit作为验收测试框架，当然可以，但它不值得做。更高级别的测试应该在软件的内部实现上依赖甚至更少，而使用JUnit（这是一个单元测试框架）编写验收测试，你引入了很多依赖于它的例子。内部函数调用。当软件设计发生任何变化时，这将是一个令人头疼的问题，高级别的测试不应该受到影响而且你是。

Answer 6

你提到了一些关于利弊的好处。我可以补充一下：

好处：我喜欢能够在不需要数据库，Web服务器的情况下测试所有内容的想法。这有助于理解代码和重构。

缺点：

JUnit代码复杂且难以维护。您必须在Junit测试中重现代码和用户之间的所有交互，这很快就会变得复杂。如果您所做的只是测试一个单一的入口点，那么这可能会有效，但如果您正在测试多个屏幕（向导或类似的东西），那么它很快就会变得脆弱且无法管理。我的经验中的问题几乎总是页面之间的管道代码，或页面所需的设置代码。

要考虑的另一件事是你要做的事情的灵活性。使用Fitnesse，如果发现错误，可以很容易地添加另一个测试。事实上，这是Fitnesse背后的想法：'用户'可以添加另一个测试，而无需更改代码。不要低估这个价值。

所以我建议两件事：

1）试试吧。记下一个用户故事（不是太复杂，不太简单），并在JUnit中完成。比较你对Selenium / Fitnesse等所做的事情，看看它是否值得。看看你是否真的发现了错误，2。产生脆弱，难以管理的代码。

2）您是否可以使用Fitnesse创建的数据作为JUnit测试的输入（从而无需Web服务器等）。您可以直接读取数据并调用Java类中的方法。同样，您可能在设置和安装方面遇到问题。数据库代码。

Answer 7

恕我直言不是一个好主意。除了你提到的2个缺点之外，如何构建一个验收测试框架所需的大量工作，这个框架将处理你可能拥有的各种web / UI /粘合方案？你的观点 “简单（不需要额外的框架）” 是不正确的，因为您的组织必须投资在JUnit之上构建更精细的框架。它可能不仅仅是JUnit。