Java 使用JUnit作为验收测试框架

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

迄今为止，我们已经尝试了Fit、Fitnesse和Selenium。每一种都有各自的优势，但我们也遇到了实际问题。有了Fit和Fitnesse，我们忍不住觉得它们太复杂了，我们在使用它们时遇到了很多技术问题。业务部门还没有完全购买这些工具，也没有特别热衷于始终维护脚本（并且不是桌面风格的忠实粉丝）。Selenium确实很好，但速度较慢，并且依赖于实时数据和资源

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

在我看来，这似乎有以下好处：

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

缺点是：

• 较少的客户参与（尽管他们在编写验收测试的第一步就大量参与编写用户故事）
• JUnit类中的用户故事和接受标准可能比freetext规范更难理解（或理解）

---

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

这不是个好主意。除了您提到的两个缺点之外，构建一个验收测试框架所需的大量工作如何，该框架将处理您可能遇到的各种web/UI/glue场景？你的观点 “简单性（不需要其他框架）”

---

这是不正确的，因为您的组织将不得不投资在JUnit之上构建更复杂的框架。这可能不仅仅是JUnit。

您提到了一些优点和缺点。我可否补充：

优点：我喜欢这样的想法，即不需要数据库和web服务器就可以测试所有内容。这对理解代码和重构有很大帮助

缺点：

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

另外一件要考虑的事情是你想做的事情的灵活性。使用Fitnesse，如果您发现一个bug，那么添加另一个测试是相当容易的。事实上，这就是Fitnesse背后的想法：“用户”可以添加另一个测试，而无需更改代码。不要低估它的价值

因此，我建议两件事：

1） 试试看。以一个用户故事（不太复杂，也不太简单）为例，在JUnit中完成它。将您所做的与Selenium/Fitnesse等进行比较，看看是否值得。看看你能不能1。事实上找到了bug，2。生成脆弱、难以管理的代码

---

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

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

现在回到验收测试。无论何时，只要您有来自客户机的故事要做，就在您的测试基础架构中为它实现测试。你写它，你运行它，你维护它。使用ADD/BDD/TDD或其他工具进行特性和驱动开发测试可能是明智的