测试

如果您正在使用Apache Causeway开发复杂的关键业务应用程序，那么能够为这些应用程序编写自动化测试非常重要。因此，Apache Causeway非常认真地对待测试主题。

本指南描述了可用于测试Apache Causeway应用程序的那些功能。

单元测试与集成测试

我们将自动化测试分为两大类：

  • 单元测试孤立地练习域对象的单个单元（通常是一种方法）。

    该对象的依赖关系被模拟出来。这些是由开发人员和开发人员编写的；它们是为了确保特定的“机器中的齿轮”正确工作

  • 集成测试将应用程序作为一个整体进行练习，通常侧重于一个特定的业务操作（操作）。

    这些测试代表了一些商业故事的验收标准；他们的意图对领域专家来说应该是有意义的（即使领域专家是“非技术性的”）

    对于较大的“模块化整体”，集成测试也可以针对应用程序的特定垂直部分运行。这个简单应用程序starter应用程序演示了这种技术。

换一种说法：

集成测试确保您建立正确的制度

单元测试确保您建立正确的制度。

集成测试利用Spring Boot的集成测试基础设施，特别是使用@SpringBoot测试。这将配置和引导Apache Causeway运行时，通常针对内存中的数据库运行。

集成测试与BDD规范

我们进一步将集成测试细分为：

  • 那些是用Java和JUnit实现的（我们简单地称之为“集成测试”)

    即使领域专家理解这些测试的意图，实际实现可能对他们来说也是相当不透明的。此外，测试的唯一输出是（希望是）绿色CI作业

  • 在行为驱动设计（BDD）语言，如黄瓜。我们称之为“BDD规范”，并提供BDD规范支持制作黄瓜和@SpringBoot测试一起工作。

    然后，自然语言规范映射到一些用于驱动应用程序的粘合代码上。但采用BDD方法的好处包括，您的领域专家将能够阅读测试/规范，并且当您运行规范时，还可以获得应用程序行为的文档（“动态文档”）。

你自己决定是否为应用程序使用BDD规范；这将取决于你的发展过程和公司文化。但如果你不这样做，那么你当然应该编写集成测试：用户故事的验收标准应该是自动化的！

模拟UI(包装厂)

当我们在这里讨论集成测试/规范时，我们指的是测试域对象逻辑，直至实际数据库。但我们也希望测试从用户的角度来测试应用程序，这意味着包括用户界面。

对于大多数其他需要使用以下工具以非常沉重/脆弱的方式测试应用程序的框架硒，驱动web浏览器进行导航。然而，在这方面，阿帕奇堤道有一个重要的秘密。因为Apache Causeway实现了裸对象模式，这意味着UI是从声明的域对象、视图和服务自动生成的。因此，这允许UI的其他实现。

这个包装厂域服务允许测试包装域对象，从而通过UI“仿佛”与所述对象交互：

包装工厂
图1。包装器对象

如果测试调用了禁用的操作，那么包装器将抛出适当的异常。如果可以调用该操作，则将其委托给。在集成测试支持第章。

这意味着可以对Apache Causeway应用程序进行端到端测试，而无需将其部署到Web服务器上；整个应用程序可以在内存中运行时进行测试。尽管集成测试（必然）比单元测试慢，但它们并不难编写（实际上，在某些方面它们更容易编写）。

依赖项注入

SpringBoot将自动向集成测试和服务中注入依赖项，Apache Causeway对此进行了扩展，将服务注入到每个域对象（实体或视图模型）中。这在编写单元测试时最有用；只需模拟服务并注入域对象。

支持多种语法，但最简单的是使用@javax.注入。注入注释；例如：

@javax.注入。注入CustomerRepository客户；

域服务由Spring Boot发现，在@导入注释，或从类路径扫描中拾取@组件扫描。任何带有注释或元注释的服务@组件可以被发现；这包括用Apache Causeway注释的类@域名服务。

给出/何时/然后

无论您正在编写什么类型的测试/规范，我们建议您遵循给定的/何时/然后的习惯用法：

  • 鉴于系统处于此状态（前提条件）

  • 什么时候我用棍子戳它

  • 然后看起来像这样（后置条件）

一个好的测试应该有5到10行长；测试应该在那里帮助您分析系统的行为。当然，如果测试超过20行，那么就很难理解了。

“when”部分通常是一句话，而“then”部分通常只有两三个断言，您希望它们表明系统已经按预期进行了更改。

对于单元测试，“给定”部分也不太难：只需实例化测试中的类，连接适当的模拟并设置期望值。如果有太多的模拟期望需要设置，那么“听听测试”……它们告诉你你的设计需要一些工作。

然而，事情变得困难的地方是集成测试的“给定”；这是下一节的主题

夹具管理

在上一节中，我们讨论了使用give/when/then作为组织测试的一种形式，以及为什么应该让测试保持较小。

对于集成测试来说，尽管很难保持“给定”的简短；在实际运行系统之前，可能需要存在大量的先决条件数据。此外，尽管我们确实设置了这些数据，但我们也希望以一种能够适应系统随时间变化的方式进行设置。

Apache Causeway提供的解决方案是fixture脚本，由名为夹具脚本。这定义了一个带有支持类的模式（命令模式和组合模式），以帮助确保测试的“数据设置”随着时间的推移是可重用和可维护的。

伪造数据

Apache Causeway提供伪造数据图书馆提供帮助。

使用假数据在fixture脚本中非常有效；fixture脚本可以使用合理的（伪/随机）默认值调用业务操作，并且只需要测试将基本信息传递给它。

功能切换

编写自动化测试只是一种良好的开发实践。此外，主线（干线、主干线）也在发展良好的实践；因此，您的持续集成系统实际上是在集成所有代码。

然而，有时一个特性的实现时间会比迭代周期长。在这种情况下，您如何使用持续集成来保持每个人都在主线上工作，而不会在您的发布版上显示一个半实现的功能？

一种选择是使用功能切换第条。这些使我们能够将部署（意味着将代码交付到生产中）与发布（意味着让用户能够访问和使用该功能）解耦。

最简单的是，功能切换可以是一个全局变量，在功能完全就绪之前禁用该功能，或者甚至可以使用安全性实现。更复杂的实现使访问更加动态，例如通过授予“alpha”或canary用户访问权限。