溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

TestContext怎么使用

發(fā)布時間:2021-12-22 11:51:28 來源:億速云 閱讀:184 作者:iii 欄目:大數(shù)據(jù)

這篇文章主要介紹“TestContext怎么使用”,在日常操作中,相信很多人在TestContext怎么使用問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”TestContext怎么使用”的疑惑有所幫助!接下來,請跟著小編一起來學(xué)習(xí)吧!

Spring TestContext 框架(位于org.springframework.test.context包中)提供了通用的、注解驅(qū)動的單元和集成測試支持,這些支持與所使用的測試框架無關(guān)。TestContext框架還非常重視約定優(yōu)于配置,你可以通過基于注解的配置覆蓋合理的默認(rèn)值。

除了通用測試基礎(chǔ)結(jié)構(gòu)之外,TestContext框架還為JUnit 4,JUnit Jupiter(AKA JUnit 5)和TestNG提供了顯式支持。對于JUnit 4和TestNG,Spring提供了抽象支持類。此外,Spring為JUnit 4提供了自定義JUnit Runner和自定義JUnit規(guī)則,以及JUnit Jupiter的自定義擴(kuò)展,可讓你編寫所謂的POJO測試類。不需要POJO測試類來擴(kuò)展特定的類層次結(jié)構(gòu),例如抽象支持類。下一節(jié)概述了TestContext框架的內(nèi)部。如果你僅對使用框架感興趣,而對使用自己的自定義監(jiān)聽器或自定義加載程序進(jìn)行擴(kuò)展不感興趣,請直接轉(zhuǎn)到配置(上下文管理 、依賴項注入、事務(wù)管理、支持類和注解支持部分。

3.5.1 關(guān)鍵抽象

該框架的核心由TestContextManager類和TestContextTestExecutionListenerSmartContextLoader接口組成。為每個測試類創(chuàng)建一個TestContextManager(例如,用于在JUnit Jupiter中的單個測試類中執(zhí)行所有測試方法)。反過來,TestContextManager管理包含當(dāng)前測試上下文的TestContext。隨著測試的進(jìn)行,TestContextManager還更新了TestContext的狀態(tài),并委托給TestExecutionListener實現(xiàn),該實現(xiàn)通過提供依賴項注入,管理事務(wù)等來檢測實際的測試執(zhí)行。SmartContextLoader負(fù)責(zé)為給定的測試類加載ApplicationContext。有關(guān)更多信息和各種實現(xiàn)的示例,請參見javadoc和Spring測試套件。

TestContext

TestContext封裝了在其中執(zhí)行測試的上下文(與使用中的實際測試框架無關(guān)),并為其負(fù)責(zé)的測試實例提供了上下文管理和緩存支持。如果需要,TestContext還委托給SmartContextLoader來加載ApplicationContext。

TestContextManager

TestContextManager是Spring TestContext 框架的主要入口點,并負(fù)責(zé)管理單個TestContext并在定義良好的測試執(zhí)行點向每個注冊的TestExecutionListener發(fā)出事件信號:

  • 在任何before類之前或在特定測試框架的所有方法之前。

  • 測試實例后處理。

  • 在任何before或在每個特定測試框架的方法之前。

  • 在執(zhí)行測試方法之前但在測試設(shè)置之后。

  • 在測試方法執(zhí)行之后,但在測試拆卸之前。

  • 之后的任何方法或之后的每一個特定的測試框架。

  • 在特定測試框架的任何類后或所有方法之后。

TestExecutionListener

TestExecutionListener定義用于對由注冊監(jiān)聽器的TestContextManager發(fā)布的測試執(zhí)行事件做出反應(yīng)的API。請參閱TestExecutionListener配置。

上下文加載器

ContextLoader是一個策略接口,用于為Spring TestContext 框架管理的集成測試加載ApplicationContext。你應(yīng)該實現(xiàn)SmartContextLoader而不是此接口,以提供對組件類,激活的bean定義配置文件、測試屬性源、上下文層次結(jié)構(gòu)和WebApplicationContext支持的支持。

SmartContextLoaderContextLoader接口的擴(kuò)展,它取代了原始的最小ContextLoader SPI。具體來說,SmartContextLoader可以選擇處理資源位置、組件類或上下文初始化器。此外,SmartContextLoader可以在其加載的上下文中設(shè)置激活Bean定義配置文件并測試屬性源。

Spring提供了以下實現(xiàn):

  • DelegatingSmartContextLoader: 它是兩個默認(rèn)加載器之一,它在內(nèi)部委派給AnnotationConfigContextLoader、GenericXmlContextLoaderGenericGroovyXmlContextLoader,具體取決于為測試類聲明的配置或默認(rèn)位置或默認(rèn)配置類的存在。僅當(dāng)Groovy在類路徑上時才啟用Groovy支持。

  • WebDelegatingSmartContextLoader: 它是兩個默認(rèn)加載器之一,它在內(nèi)部委派給AnnotationConfigWebContextLoader、GenericXmlWebContextLoader或GenericGroovyXmlWebContextLoader,具體取決于為測試類聲明的配置或默認(rèn)位置或默認(rèn)配置類的存在。僅當(dāng)測試類上存在@WebAppConfiguration時,才使用Web ContextLoader。僅當(dāng)Groovy在類路徑上時才啟用Groovy支持。

  • AnnotationConfigContextLoader:從組件類加載標(biāo)準(zhǔn)ApplicationContext。

  • AnnotationConfigWebContextLoader: 從組件類加載WebApplicationContext。

  • GenericGroovyXmlContextLoader: 從Groovy腳本或XML配置文件的資源位置加載標(biāo)準(zhǔn)ApplicationContext。

  • GenericGroovyXmlWebContextLoader: 從Groovy腳本或XML配置文件的資源位置加載WebApplicationContext。

  • GenericXmlContextLoader: 從XML資源位置加載標(biāo)準(zhǔn)ApplicationContext。

  • GenericXmlWebContextLoader: 從XML資源位置加載WebApplicationContext。

  • GenericPropertiesContextLoader:從Java屬性文件加載標(biāo)準(zhǔn)ApplicationContext

3.5.2 引導(dǎo)TestContext框架

Spring TestContext 框架內(nèi)部的默認(rèn)配置足以滿足所有常見用例。但是,有時開發(fā)團(tuán)隊或第三方框架希望更改默認(rèn)的ContextLoader,實現(xiàn)自定義的TestContextContextCache,擴(kuò)展默認(rèn)的ContextCustomizerFactoryTestExecutionListener實現(xiàn)等等。為了對TestContext框架的運行方式進(jìn)行低級別控制,Spring提供了引導(dǎo)策略。

TestContextBootstrapper定義了用于引導(dǎo)TestContext框架的SPI。TestContextManager使用TestContextBootstrapper加載當(dāng)前測試的TestExecutionListener實現(xiàn)并構(gòu)建它管理的TestContext。你可以直接使用@BootstrapWith或作為元注解,為測試類(或測試類層次結(jié)構(gòu))配置自定義引導(dǎo)策略。如果沒有通過使用@BootstrapWith顯式配置引導(dǎo)程序,則根據(jù)@WebAppConfiguration的存在,使用DefaultTestContextBootstrapperWebTestContextBootstrapper。

由于TestContextBootstrapper SPI將來可能會更改(以適應(yīng)新的需求),我們強烈建議實現(xiàn)者不要直接實現(xiàn)此接口,而應(yīng)擴(kuò)展AbstractTestContextBootstrapper或其具體子類之一。

3.5.3 TestExecutionListener配置

Spring提供了以下TestExecutionListener實現(xiàn),這些實現(xiàn)默認(rèn)情況下按以下順序注冊:

  • ServletTestExecutionListener:為WebApplicationContext配置Servlet API模擬。

  • DirtiesContextBeforeModesTestExecutionListener:處理before模式的@DirtiesContext注解。

  • DependencyInjectionTestExecutionListener: 為測試實例提供依賴項注入。

  • DirtiesContextTestExecutionListener: 處理after模式的@DirtiesContext注解。

  • TransactionalTestExecutionListener: 提供具有默認(rèn)回滾語義的事務(wù)測試執(zhí)行。

  • SqlScriptsTestExecutionListener: 運行使用@Sql注釋配置的SQL腳本。

  • EventPublishingTestExecutionListener: 將測試執(zhí)行事件發(fā)布到測試的ApplicationContext中(請參閱測試執(zhí)行事件)。

注冊TestExecutionListener實現(xiàn)

你可以使用@TestExecutionListeners注解為測試類及其子類注解TestExecutionListener實現(xiàn)。有關(guān)詳細(xì)信息和示例,請參見注解支持和@TestExecutionListeners的javadoc。

默認(rèn)TestExecutionListener實現(xiàn)自動發(fā)現(xiàn)

通過使用@TestExecutionListeners注冊TestExecutionListener實現(xiàn)適用于有限測試方案中使用的自定義監(jiān)聽器。但是,如果需要在整個測試套件中使用自定義監(jiān)聽器,則會變得很麻煩。通過SpringFactoriesLoader機(jī)制支持自動發(fā)現(xiàn)默認(rèn)的TestExecutionListener實現(xiàn),可以解決這個問題。

具體來說,spring-test模塊在其META-INF/spring.factories屬性文件中的keyorg.springframework.test.context.TestExecutionListener下聲明所有核心默認(rèn)TestExecutionListener實現(xiàn)。第三方框架和開發(fā)人員可以通過自己的META-INF/spring.factories屬性文件以相同的方式將自己的TestExecutionListener實現(xiàn)貢獻(xiàn)到默認(rèn)監(jiān)聽器列表中。

TestExecutionListener順序?qū)崿F(xiàn)

當(dāng)TestContext框架通過上述SpringFactoriesLoader機(jī)制發(fā)現(xiàn)默認(rèn)TestExecutionListener實現(xiàn)時,實例化的監(jiān)聽器將使用Spring的AnnotationAwareOrderComparator進(jìn)行排序,該類將使用Spring的Ordered接口和@Order注解進(jìn)行排序。Spring提供的AbstractTestExecutionListener和所有默認(rèn)的TestExecutionListener實現(xiàn)以適當(dāng)?shù)闹祵崿F(xiàn)Ordered。因此,第三方框架和開發(fā)人員應(yīng)通過實施Ordered或聲明@Order來確保按默認(rèn)順序注冊其默認(rèn)的TestExecutionListener實現(xiàn)。請參閱javadoc以獲取核心默認(rèn)TestExecutionListener實現(xiàn)的getOrder()方法,以獲取有關(guān)為每個核心監(jiān)聽器分配哪些值的詳細(xì)信息。

TestExecutionListener合并實現(xiàn)

如果通過@TestExecutionListeners注冊了自定義TestExecutionListener,則不會注冊默認(rèn)監(jiān)聽器。在大多數(shù)常見的測試方案中,這有效地迫使開發(fā)人員手動聲明除任何自定義監(jiān)聽器之外的所有默認(rèn)監(jiān)聽器。

下面的清單演示了這種配置樣式:

@ContextConfiguration
@TestExecutionListeners({
    MyCustomTestExecutionListener.class,
    ServletTestExecutionListener.class,
    DirtiesContextBeforeModesTestExecutionListener.class,
    DependencyInjectionTestExecutionListener.class,
    DirtiesContextTestExecutionListener.class,
    TransactionalTestExecutionListener.class,
    SqlScriptsTestExecutionListener.class
})
class MyTest {
    // class body...
}

這種方法的挑戰(zhàn)在于,它要求開發(fā)人員確切地知道默認(rèn)情況下注冊了哪些監(jiān)聽器。此外,默認(rèn)的監(jiān)聽器集可以隨版本的不同而變化-例如,在Spring框架4.1中引入了SqlScriptsTestExecutionListener,在Spring框架4.2中引入了DirtiesContextBeforeModesTestExecutionListener。此外,諸如Spring Boot和Spring Security之類的第三方框架通過使用上述自動發(fā)現(xiàn)機(jī)制注冊了自己的默認(rèn)TestExecutionListener實現(xiàn)。

為避免必須了解并重新聲明所有默認(rèn)監(jiān)聽器,可以將@TestExecutionListenersmergeMode屬性設(shè)置為MergeMode.MERGE_WITH_DEFAULTS。MERGE_WITH_DEFAULTS表示應(yīng)將本地聲明的監(jiān)聽器與默認(rèn)監(jiān)聽器合并。合并算法可確保從列表中刪除重復(fù)項,并確保根據(jù)AnnotationAwareOrderComparator的語義對合并后的監(jiān)聽器集進(jìn)行排序,如Ordering TestExecutionListener實現(xiàn)中所述。如果監(jiān)聽器實現(xiàn)Ordered或使用@Order進(jìn)行注解,則它可以影響將其與默認(rèn)值合并的位置。否則,合并時,本地聲明的監(jiān)聽器將追加到默認(rèn)偵聽器列表中。

例如,如果上一個示例中的MyCustomTestExecutionListener類將順序值(例如500)配置為小于ServletTestExecutionListener的順序(恰好是1000),則MyCustomTestExecutionListener可以自動與默認(rèn)列表合并。在ServletTestExecutionListener前面,并且前面的示例可以替換為以下示例:

@ContextConfiguration
@TestExecutionListeners(
    listeners = MyCustomTestExecutionListener.class,
    mergeMode = MERGE_WITH_DEFAULTS
)
class MyTest {
    // class body...
}

3.5.4 測試執(zhí)行事件

Spring框架5.2中引入的EventPublishingTestExecutionListener提供了一種實現(xiàn)自定義TestExecutionListener的替代方法。測試的ApplicationContext中的組件可以監(jiān)聽EventPublishingTestExecutionListener發(fā)布的以下事件,每個事件都與TestExecutionListener API中的方法相對應(yīng)。

  • BeforeTestClassEvent

  • PrepareTestInstanceEvent

  • BeforeTestMethodEvent

  • BeforeTestExecutionEvent

  • AfterTestExecutionEvent

  • AfterTestMethodEvent

  • AfterTestClassEvent

只有當(dāng)ApplicationContext已經(jīng)加載時,才會發(fā)布這些事件。

這些事件可能由于各種原因被使用,例如重置模擬bean或跟蹤測試執(zhí)行。使用測試執(zhí)行事件而不是實現(xiàn)自定義TestExecutionListener的一個優(yōu)勢是,測試執(zhí)行事件可以由在測試ApplicationContext中注冊的任何Spring bean所使用,并且此類bean可以直接受益于依賴項注入和ApplicationContext的其他功能。相反,TestExecutionListenerApplicationContext中不是bean。

為了監(jiān)聽測試執(zhí)行事件,Spring Bean可以選擇實現(xiàn)org.springframework.context.ApplicationListener接口?;蛘?,可以使用@EventListener注解監(jiān)聽器方法,并將監(jiān)聽方法配置為監(jiān)聽上面列出的特定事件類型之一(請參閱基于注解的事件監(jiān)聽器)。由于這種方法的流行,Spring提供了以下專用的@EventListener注解,以簡化測試執(zhí)行事件監(jiān)聽器的注冊。這些注解駐留在org.springframework.test.context.event.annotation包中。

  • @BeforeTestClass

  • @PrepareTestInstance

  • @BeforeTestMethod

  • @BeforeTestExecution

  • @AfterTestExecution

  • @AfterTestMethod

  • @AfterTestClass

異常處理

默認(rèn)情況下,如果測試執(zhí)行事件監(jiān)聽器在使用事件時拋出異常,則該異常將傳播到使用中的基礎(chǔ)測試框架(例如JUnit或TestNG)。例如,如果使用BeforeTestMethodEvent導(dǎo)致異常,則相應(yīng)的測試方法將因異常而失敗。相反,如果異步測試執(zhí)行事件監(jiān)聽器引發(fā)異常,則該異常不會傳播到基礎(chǔ)測試框架。有關(guān)異步異常處理的更多詳細(xì)信息,請查閱@EventListener類級javadoc。

異步監(jiān)聽器

如果你希望特定的測試執(zhí)行事件監(jiān)聽器異步處理事件,你可以使用Spring的常規(guī)@Async支持。有關(guān)更多詳細(xì)信息,請查閱@EventListener的類級javadoc。

到此,關(guān)于“TestContext怎么使用”的學(xué)習(xí)就結(jié)束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí),快去試試吧!若想繼續(xù)學(xué)習(xí)更多相關(guān)知識,請繼續(xù)關(guān)注億速云網(wǎng)站,小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>

向AI問一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI