java - 使用 JUnit 作为验收测试框架

Question

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

迄今为止，我们已经尝试过 Fit、Fitnesse 和 Selenium。每个人都有自己的优势，但我们也遇到了真正的问题。使用 Fit 和 Fitnesse，我们不禁觉得它们使事情变得过于复杂，而且我们在使用它们时遇到了许多技术问题。企业还没有完全购买这些工具，也不是一直特别热衷于维护脚本(并且不是表格样式的忠实粉丝)。 Selenium 非常好，但速度很慢，并且依赖于实时数据和资源。

我们现在正在考虑的一种方法是使用 JUnit 框架来提供类似的功能。为什么不使用 JUnit 来编写一个测试(使用 JUnit 框架)来覆盖应用程序的可接受水平范围，而不是使用 JUnit 测试一个小的工作单元？ IE。拿一个新故事(“作为用户，我想查看我的策略的基本细节......”)并在 JUnit 中编写一个测试，该测试在策略细节链接的入口处开始执行应用程序代码，但涵盖所有代码和逻辑向下到 stub 数据访问层并返回到转发到应用程序中的下一页的点，断言用户应该在该页面上看到什么数据。

这在我看来有以下优点:

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

缺点是:

• 更少的客户参与(尽管他们首先会大量参与编写验收测试的用户故事)
• 与自由文本规范(如 Fit 或 Fitnesse)相比，JUnit 类中的用户故事和接受标准可能更难理解(或让人理解)

所以，我的问题是，你有没有试过这种方法？有没有考虑过？你觉得呢？你有没有什么想法？您喜欢和不喜欢这种方法的哪些方面？最后，如果你能说出你喜欢或不喜欢它们的原因，请只提及替代框架而不是这种方法。

Answer 1

我将 JUnit 用于验收测试框架的经验。

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

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

优点:

• JUnit 具有很大的灵 active (因为它是 Java)，因此创建内部 Domain Specific Language 相对容易[福勒]。 DSL 可以进行修改，以便领域专家(而非软件工程师)轻松读/写。
• 由于它是 JUnit，您可以将 Eclipse 用作 IDE，它为您提供自动完成、语法检查、调试等功能。
• 对于我们的应用程序，我们有一个 CORBA 界面到 UI。 Java 也可以很容易地使用这个 CORBA 接口(interface)。

缺点:

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

总而言之，如果您愿意花时间将 JUnit 扩展到您自己的特定领域测试环境中，那么 JUnit 就可以很好地用于验收测试。否则我想我会在别处寻找更多开箱即用的东西。