AEM中的单元测试（大声思考）

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

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

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

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

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

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

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

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

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