aem 渲染

如果要在AEM中进行单元测试，这不是任何建议，而是各种思想的总结和一些可供选择的选项。 一段时间之前，我已经为客户进行了一些研究，这篇文章在很大程度上受到了这项工作的影响，但是很多上下文相关的东西已经被淘汰了。 我仍然尽力确保本文的精髓。 我将尝试尽快进行后续处理，并提供更多详细信息。

选项1：使用吊索工具并测试容器内

Apache sling已发布了一组工具http://sling.apache.org/documentation/development/sling-testing-tools.html ，可协助应用程序中的单元测试。 那里的工具提供了几种执行测试的方法，例如a）没有外部依赖关系的老式JUnit，或者b）使用模拟程序–吊索提供了现成的模拟程序，可以减少工作量，或者c）我们可以在CQ盒中部署测试用例（或吊索），然后使用OSGi引用运行。

我在这里建议的方法是，我们将在已经托管的CQ实例中部署JUnit，并远程调用测试用例。 我了解这不是“老学校单元测试，因为我没有抽象任何依赖关系，并且我的单元包括依赖关系”，但是我有这样做的理由。 事实上，如果您一直关注我关于单元测试的文章，您会知道我不是模拟的忠实拥护者，并且如果我可以进行设置，那么实际上我很乐意针对依赖项进行任何单元测试。

为此，我们需要做一些事情，如下所示：

1. 我们将需要一个托管的CQ实例，可以用作运行测试用例的容器
   1. 我们可以使用嵌入式系统，但是随后我们将不得不花更多的精力来创建内容，而不能创建其他内容。 另外，嵌入式容器将是吊索而不是CQ，我们希望使环境尽可能接近我们使用的环境
2. CQ实例应具有一组预填充的产品和图像（此设置确实使用了AEM电子商务模块，并且PIM和DAM已与外部系统集成在一起），并且可以作为我们的现成测试数据。 这些可以通过我们的后端集成来实现。 我们可以选择独立执行或自动执行（随着时间的流逝，这些事情的自动化也可能发生，以便我们快速启动）
3. 为了与任何后端服务（例如订单管理，定价，帐户信息）进行交互，我们需要运行一个后端服务实例（如我所说，如果可能的话，我会选择系统而不是模拟系统），并设置所有变量和部件。 该实例还应该具有各种数据设置，例如用户帐户，产品实例，可用性，价格等，以确保我们的用例能够正常工作。 设置独立的后端服务存在明显的挑战，我们可以探索以下2个选项之一
   1. 捕获特定请求类型的所有请求和响应，并将其序列化到测试数据存储中。 它可以是巨大的XML，可以存储在系统的键值对中，也可以是像mongo这样的数据库（甚至可以使用SQL），也可以在文件系统上序列化；或者
   2. 我们可以使用一个已经存在的后端系统

选项2：使用Selenium作为功能测试工具

在这种方法中，我建议根本不要使用JUnits。 这个想法是使用系统测试的原理，它可以测试代码中的所有单元。 这与模拟所有依赖项的传统单元测试方法大不相同，我们可以快速运行多个测试。 尽管选项1也具有相同的效果，但在这种方法中，我们更进一步，并利用了我们的系统测试套件。 这个想法不是针对每个用例都执行此操作，而是获取关键业务功能，例如结帐，订单管理，帐户管理并使其自动化。 然后可以将Selenium脚本与JUnit运行器集成，在这里我们可以将其与CI工具集成，并可以从Eclipse或Maven运行它，因此可以与CI本身集成。 这为我们节省了编写那些JUnit和独立管理整个套件的时间。 这种方法还需要一个托管的CQ实例，该实例具有产品数据设置，一些内容设置和后端集成，就像在选项1中一样。

当然，这有点棘手，不是真正的单元测试，但是如果做得好，它会有一些巨大的好处。

翻译自: https://www.javacodegeeks.com/2015/01/unit-testing-in-aem-thinking-loud.html

aem 渲染