aem 渲染
如果要在AEM中进行单元测试,这不是任何建议,而是各种思想的总结和一些可供选择的选项。 一段时间之前,我已经为客户进行了一些研究,这篇文章在很大程度上受到了这项工作的影响,但是很多上下文相关的东西已经被淘汰了。 我仍然尽力确保本文的精髓。 我将尝试尽快进行后续处理,并提供更多详细信息。
选项1:使用吊索工具并测试容器内
Apache sling已发布了一组工具http://sling.apache.org/documentation/development/sling-testing-tools.html ,可协助应用程序中的单元测试。 那里的工具提供了几种执行测试的方法,例如a)没有外部依赖关系的老式JUnit,或者b)使用模拟程序–吊索提供了现成的模拟程序,可以减少工作量,或者c)我们可以在CQ盒中部署测试用例(或吊索),然后使用OSGi引用运行。
我在这里建议的方法是,我们将在已经托管的CQ实例中部署JUnit,并远程调用测试用例。 我了解这不是“老学校单元测试,因为我没有抽象任何依赖关系,并且我的单元包括依赖关系”,但是我有这样做的理由。 事实上,如果您一直关注我关于单元测试的文章,您会知道我不是模拟的忠实拥护者,并且如果我可以进行设置,那么实际上我很乐意针对依赖项进行任何单元测试。
为此,我们需要做一些事情,如下所示:
- 我们将需要一个托管的CQ实例,可以用作运行测试用例的容器
- 我们可以使用嵌入式系统,但是随后我们将不得不花更多的精力来创建内容,而不能创建其他内容。 另外,嵌入式容器将是吊索而不是CQ,我们希望使环境尽可能接近我们使用的环境
- CQ实例应具有一组预填充的产品和图像(此设置确实使用了AEM电子商务模块,并且PIM和DAM已与外部系统集成在一起),并且可以作为我们的现成测试数据。 这些可以通过我们的后端集成来实现。 我们可以选择独立执行或自动执行(随着时间的流逝,这些事情的自动化也可能发生,以便我们快速启动)
- 为了与任何后端服务(例如订单管理,定价,帐户信息)进行交互,我们需要运行一个后端服务实例(如我所说,如果可能的话,我会选择系统而不是模拟系统),并设置所有变量和部件。 该实例还应该具有各种数据设置,例如用户帐户,产品实例,可用性,价格等,以确保我们的用例能够正常工作。 设置独立的后端服务存在明显的挑战,我们可以探索以下2个选项之一
- 捕获特定请求类型的所有请求和响应,并将其序列化到测试数据存储中。 它可以是巨大的XML,可以存储在系统的键值对中,也可以是像mongo这样的数据库(甚至可以使用SQL),也可以在文件系统上序列化;或者
- 我们可以使用一个已经存在的后端系统
选项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 渲染