如果要在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：使用硒作為功能測試工具

在這種方法中，我建議根本不要使用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中的单元测试（大声思考）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。