2016-10-03 100 views
4

背景單元測試AEM 6.1和嘲諷吊帶,JCR和OSGi

嗨,

所以我最近在使用AEM 6.1公司開始,我也是一個初級開發。

當我與我的好友(高級開發人員)配對時,他通常會開車。但是不寫單元測試,這讓我感到困惑。他解釋說,單元測試AEM很困難。

我們的項目使用http sling請求和響應,Osgi框架和一個大的Jcr存儲庫,jsps,servlets和數據庫連接。我們使用各種設計模式,創建適配器類......等等。

問題

爲什麼很難創造AEM單元測試,當有嘲諷的吊帶,OSGi和JCR框架?

如何學會單元測試AEM 6.1?

前進...

我正在尋找資源,能夠爲AEM創建單元測試?如果可能的話,你可以鏈接下面的任何資源?

回答

2

當我第一次開始在AEM中開發時,我也有同樣的感受。隨着時間的推移,我推動爲我的公司改變這種狀況,現在我們有了一個單元測試我們的AEM代碼的環境。

爲什麼測試AEM代碼很困難?我認爲主要原因歸結爲2點:

  1. 許多Adobe示例以帶有內嵌Java代碼(scriptlets)的JSP形式出現。 Scriptlet代碼不可測試,也不可重用。我認爲你從Adobe看到如此之多的一個原因是,該產品允許開發人員「覆蓋」基本功能。內置代碼在「libs」下運行,但開發人員可以將代碼複製到libs中,並將其放在「apps」中,然後進行更改 - 這些更改將替代現有代碼生效。使用包含scriptlet的JSP,可以很容易地替換這樣的代碼,因爲您可以獲取標記以及Java代碼,並仍然可以對其進行更改。但是如果該Java代碼位於其他庫中,那麼您如何替換它?雖然這是可能的,但會更困難。所以我認爲Adobe有很多示例代碼在腳本中顯示Java代碼。但這是不好的做法,不管其原因。如果你想單元測試,你不能這樣做。所以不要允許它。要求開發人員將代碼放在.java類中,並通過標籤(或其他類似的機制)包含它。然後你可以單元測試代碼 - 並且更容易重用它。
  2. 您爲AEM編寫的大部分代碼都需要與AEM使用的存儲庫進行交互。所以你不可避免地對作爲基本AEM安裝一部分的代碼/包有依賴性。當您嘗試編寫自己的.java類時,您很快就會發現,除非在IDE的類路徑中具有這些相同的依賴項,否則將無法編譯。對於較老的AEM版本,沒有供應商提供的方式來獲取這些知識。但最近的版本有它 - 一個「Uber」.jar。我認爲依賴性問題阻礙了開發人員。他們在JSP中恢復爲它們的Java代碼中的scriptlet。如果要單元測試AEM代碼,則必須提取AEM提供的代碼中的所有依賴關係,並將其作爲IDE中項目的一部分。這不是一件容易的事情,但它是能夠在IDE中以正常方式進行有效開發和測試以及像在其他Java項目中一樣持續集成構建項目的先決條件。

我們通過製作一個「容器」.jar解決了#2問題,該容器包含我們AEM實例中需要編譯和單元測試Java代碼的所有.jar文件。但是最近的AEM版本在Uber .jar中提供了這個功能,這使得這項任務變得更加容易。我們還使用Mockito進行單元測試Java代碼。它允許我們依賴的Sling和AEM類輕鬆而強大地嘲笑。我們一直使用它。我們偶爾也會使用PowerMockito進行一些嘲諷。

除此之外,測試用於AEM的Java代碼是否比測試任何其他Java代碼更困難。我們還使用Karma和Jasmine添加了JavaScript單元測試支持 - 所以同樣的事情適用於客戶端代碼。

這裏有一些資源,可以幫助:

1

這取決於代碼,一個代碼,你可以很容易地與其他測試覆蓋測試。支持這種「不可測試」代碼的單元測試(創建代碼時不考慮測試)是一件很痛苦的事情。

在這裏你可以找到庫的單元測試link與例子。

你也可以測試你的代碼,如Mockito(在許多情況下,更容易與Mockito創建模擬,而不是在Sling模擬庫中創建JCR fixture from JSON file)。

0

一個主要問題是uber jar被混淆,因此它只包含API接口和類。因此,您必須模擬AEM對象,這非常麻煩。但是,Adobe提供了一個未混淆的超級罐。

0

爲AEM編寫測試應該不難,Apache Sling社區提供了在不同級別測試的方法,因爲AEM基於Sling,我們可以使用相同的工具。

結帳以下鏈接: