JavaRush /Kurslar /All lectures for UZ purposes /Test Annotatsiyalari

Test Annotatsiyalari

All lectures for UZ purposes

Daraja, Dars

Mavjud

Spring Framework da TestContext framevori bilan birgalikda foydalanishingiz mumkin bo'lgan Springga xos bo'lgan quyidagi annotatsiyalar to'plami mavjud. Qo'shimcha ma'lumot olish uchun tegishli javadocni ko'ring, jumladan standart atribut qiymatlari, atribut taxalluslari va boshqa ma'lumotlar.

Springda test qilish uchun quyidagi annotatsiyalar mavjud:

`@BootstrapWith`

@BootstrapWith — bu Spring TestContext Frameworkni yuklash usulini sozlash uchun ishlatilishi mumkin bo'lgan sinf darajasidagi annotatsiya. Xususan, maxsus TestContextBootstrapperni o'rnatish uchun @BootstrapWithdan foydalanish mumkin. Qo'shimcha ma'lumotlarni TestContext Frameworkni yuklashga bag'ishlangan bo'limida ko'ring.

`@ContextConfiguration`

@ContextConfiguration annotatsiyasi integratsion testlar uchun ApplicationContextni qanday yuklash va sozlashni aniqlovchi metama'lumotlarni sinf darajasida aniqlaydi. Xususan, @ContextConfiguration kontekstni yuklash uchun foydalaniladigan ilova konteksti resurslari locationsni yoki komponent classesni e'lon qiladi.

Resurslarning joylashuvi odatda classpathda joylashgan XML konfiguratsiya fayllari yoki Groovy skriptlari bo'lib, komponentlar sinflari odatda @Configuration annotatsiyalangan sinflardir. Biroq, resurslarning joylashuvi fayl tizimidagi fayl va skriptlarga ham ishora qilishi mumkin va komponentlar sinflari @Component, @Service va boshqalar kabi annotatsiyalangan sinflar bo'lishi mumkin. Qo'shimcha ma'lumotlarni "Komponent sinflari"ga bag'ishlangan bo'limida ko'ring.

Quyidagi misol @ContextConfiguration annotatsiyasini XML fayliga ishora qilishini ko'rsatadi:

Java

@ContextConfiguration("/test-config.xml") 
class XmlApplicationContextTests {
    // sinfning tanasi...
}

XML fayliga ishora qilamiz.

Kotlin

@ContextConfiguration("/test-config.xml") 
class XmlApplicationContextTests {
    // sinfning tanasi...
}

XML fayliga ishora qilamiz.

Quyidagi misol @ContextConfiguration annotatsiyasini sinfga ishora qilishini ko'rsatadi:

Java

@ContextConfiguration(classes = TestConfig.class) 
class ConfigClassApplicationContextTests {
    // sinfning tanasi...
}

Sinfga ishora qilamiz.

Kotlin

@ContextConfiguration(classes = [TestConfig::class]) 
class ConfigClassApplicationContextTests {
    // sinfning tanasi...
}

Sinfga ishora qilamiz.

Resurslar joylashuvini yoki komponent sinflarni e'lon qilishning o'rniga yoki qo'shimcha ravishda, @ContextConfiguration ni ApplicationContextInitializer sinflarini e'lon qilish uchun ishlatish mumkin. Quyidagi misol bunday holatni ko'rsatadi:

Java

@ContextConfiguration(initializers = CustomContextInitializer.class) 
class ContextInitializerTests {
    // sinfning tanasi...
}

Initializer sinfni e'lon qilamiz.

Kotlin

@ContextConfiguration(initializers = [CustomContextInitializer::class]) 
class ContextInitializerTests {
    // sinfning tanasi...
}

Initializer sinfni e'lon qilamiz.

Shuningdek, @ContextConfiguration annotatsiyasini ContextLoader strategiyasini e'lon qilish uchun ishlatish mumkin. Biroq, ko'pincha yuklovchini aniq sozlash shart emas, chunki standart yuklovchi initializers va locations resurslarini yoki komponent sinflarni qo'llab-quvvatlaydi.

Quyidagi misol joylashuv va yuklovchini ishlatishni ko'rsatadi:

Java

@ContextConfiguration(locations = "/test-context.xml", loader = CustomContextLoader.class) 
class CustomLoaderXmlApplicationContextTests {
    // sinfning tanasi...
}

Joylashuv va maxsus yuklovchini sozlaymiz.

Kotlin

@ContextConfiguration("/test-context.xml", loader = CustomContextLoader::class) 
class CustomLoaderXmlApplicationContextTests {
    // sinfning tanasi...
}

Joylashuv va maxsus yuklovchini sozlaymiz.

@ContextConfiguration superklasslar yoki qamrab oluvchi sinflar tomonidan e'lon qilingan resurslar joylashuvi yoki konfiguratsiya sinflari va kontekst initsializatorlarini meros qilib olishni qo'llab-quvvatlaydi.

Qo'shimcha ma'lumotlarni kontekstni boshqarish, tartiblangan test sinf konfiguratsiyasi va @ContextConfiguration annotatsiyasiga tegishli javadocsda ko'ring.

`@WebAppConfiguration`

@WebAppConfiguration — bu sinf darajasidagi annotatsiya bo'lib, uni integratsion test uchun yuklanadigan ApplicationContext WebApplicationContext bo'lishi kerakligini e'lon qilish uchun ishlatish mumkin. @WebAppConfiguration annotatsiyasining o'zi mavjudligi, test uchun WebApplicationContext yuklanishini ta'minlaydi, veb-ilova ildiz yo'li uchun standart qiymat "file:src/main/webapp" bilan (ya'ni, asosiy resurs yo'li). Asosiy resurs yo'li "yashirin" tarzda MockServletContext yaratish uchun ishlatiladi, bu WebApplicationContext testining ServletContexti sifatida xizmat qiladi.

Quyidagi misol @WebAppConfiguration annotatsiyasidan qanday foydalanishni ko'rsatadi:

Java

@ContextConfiguration
@WebAppConfiguration 
class WebAppTests {
    // sinfning tanasi...
}

@WebAppConfiguration annotatsiyasi.

Kotlin

@ContextConfiguration
@WebAppConfiguration 
class WebAppTests {
    // sinfning tanasi...
}

@WebAppConfiguration annotatsiyasi.

Standart qiymatni o'zgartirish uchun, value atributi yordamida boshqa asosiy resurs yo'lini belgilashingiz mumkin. classpath: va file: resurs prefikslari qo'llab-quvvatlanadi. Agar resurs prefiksi ko'rsatilmagan bo'lsa, yo'l fayl tizimi resursi deb hisoblanadi. Quyidagi misol classpath: resursini belgilashni ko'rsatadi:

Java

@ContextConfiguration
@WebAppConfiguration("classpath:test-web-resources") 
class WebAppTests {
    // sinfning tanasi...
}

classpath resursini belgilaymiz.

Kotlin

@ContextConfiguration
@WebAppConfiguration("classpath:test-web-resources") 
class WebAppTests {
    // sinfning tanasi...
}

classpath resursini belgilaymiz.

@WebAppConfiguration annotatsiyasini @ContextConfiguration annotatsiyasi bilan birga bir test sinfida yoki sinflar ierarxiyasida ishlatish kerakligini yodda tuting. Qo'shimcha ma'lumotni @WebAppConfiguration annotatsiyasi bo'yicha javadocda ko'ring.

`@ContextHierarchy`

@ContextHierarchy — bu sinf darajasidagi annotatsiya bo'lib, integratsion testlar uchun ApplicationContext instansiyalari iyerarxiyasini aniqlash uchun ishlatiladi. @ContextHierarchy annotatsiyasini @ContextConfiguration annotatsiyalarining bir yoki bir nechta misollaridan foydalangan holda e'lon qilinishi kerak, ularning har biri kontekst ierarxiyasida bir daraja aniqlaydi. Quyidagi misollar bitta test sinfi doirasida @ContextHierarchy annotatsiyasidan foydalanishni ko'rsatadi (@ContextHierarchy annotatsiyasini sinf iyerarxiyasida ham ishlatish mumkin):

Java

@ContextHierarchy({
    @ContextConfiguration("/parent-config.xml"),
    @ContextConfiguration("/child-config.xml")
})
class ContextHierarchyTests {
    // sinfning tanasi...
}

Kotlin

@ContextHierarchy(
    ContextConfiguration("/parent-config.xml"),
    ContextConfiguration("/child-config.xml"))
class ContextHierarchyTests {
    // sinfning tanasi...
}

Java

@WebAppConfiguration
@ContextHierarchy({
    @ContextConfiguration(classes = AppConfig.class),
    @ContextConfiguration(classes = WebConfig.class)
})
class WebIntegrationTests {
    // sinfning tanasi...
}

Kotlin

@WebAppConfiguration
@ContextHierarchy(
        ContextConfiguration(classes = [AppConfig::class]),
        ContextConfiguration(classes = [WebConfig::class]))
class WebIntegrationTests {
    // sinfning tanasi...
}

Agar sinf iyerarxiyasida ma'lum bir kontekst darajasiga yoki qismiga konfiguratsiyani birlashtirish yoki ustunlik qilish kerak bo'lsa, bu daraja nomini aniq belgilashingiz kerak, @ContextConfiguration annotatsiyasida har bir tegishli sinflar iyerarxiyasida name atributiga bir xil qiymat berish orqali. Qo'shimcha misollarni "Kontekst iyerarxiyalari" bo'limida va @ContextHierarchy annotatsiyasiga tegishli javadoclarda ko'rib chiqishingiz mumkin.

`@ActiveProfiles`

@ActiveProfiles — bu sinf darajasidagi annotatsiya bo'lib, u integratsion test uchun ApplicationContextni yuklashda qaysi bean definition profillari faol bo'lishi kerakligini e'lon qilish uchun ishlatiladi.

Quyidagi misol dev profilining faol bo'lishi kerakligini ko'rsatadi:

Java

@ContextConfiguration
@ActiveProfiles("dev") 
class DeveloperTests {
    // sinfning tanasi...
}

dev profilining faol bo'lishini belgilaymiz.

Kotlin

@ContextConfiguration
@ActiveProfiles("dev") 
class DeveloperTests {
    // sinfning tanasi...
}

dev profilining faol bo'lishini belgilaymiz.

Quyidagi misol dev va integration profillarning faol bo'lishi kerakligini ko'rsatadi:

Java

@ContextConfiguration
@ActiveProfiles({"dev", "integration"}) 
class DeveloperIntegrationTests {
    // sinfning tanasi...
}

dev va integration profillarning faol bo'lishini belgilaymiz.

Kotlin

@ContextConfiguration
@ActiveProfiles(["dev", "integration"]) 
class DeveloperIntegrationTests {
    // sinfning tanasi...
}

dev va integration profillarning faol bo'lishini belgilaymiz.

@ActiveProfiles annotatsiyasi standart holda superklasslar va qamrab oluvchi sinflar tomonidan e'lon qilingan faol bean definition profillarning meros qilib olinishi qo'llab-quvvatlaydi. Siz shuningdek, ActiveProfilesResolver ni amalga oshirish va @ActiveProfiles annotatsiyasiga resolver atributi yordamida uni registratsiya qilish orqali faol bean definition profillarni dasturlashtirib aniqlashingiz mumkin.

A'zo bo'limlari: "Muhit profillari bilan kontekst konfiguratsiyasi", "Tartiblangan test sinf konfiguratsiyasi" va @ActiveProfiles annotatsiyasiga tegishli javadocsni ko'ring.

`@TestPropertySource`

@TestPropertySource sinf darajasidagi annotatsiya bo'lib, u testli integratsion test uchun yuklangan ApplicationContext muhiti uchun PropertySources ga qo'shiladigan property fayllari joylashuvlari va ichki propertylarni konfiguratsiya qilish uchun ishlatiladi.

Quyidagi misol classpathdan property faylini qanday e'lon qilishni ko'rsatadi:

Java

@ContextConfiguration
@TestPropertySource("/test.properties") 
class MyIntegrationTests {
    // sinfning tanasi...
}

test.properties classpath rootdan propertiesni olib kelamiz.

Kotlin

@ContextConfiguration
@TestPropertySource("/test.properties") 
class MyIntegrationTests {
    // sinfning tanasi...
}

test.properties classpath rootdan propertiesni olib kelamiz.

Quyidagi misol ichki propertylarni qanday e'lon qilishni ko'rsatadi:

Java

@ContextConfiguration
@TestPropertySource(properties = { "timezone = GMT", "port: 4242" }) 
class MyIntegrationTests {
    // sinfning tanasi...
}

timezone va port propertylarini e'lon qilamiz.

Kotlin

@ContextConfiguration
@TestPropertySource(properties = ["timezone = GMT", "port: 4242"]) 
class MyIntegrationTests {
    // sinfning tanasi...
}

timezone va port propertylarini e'lon qilamiz.

Qo'shimcha ma'lumotlarni "Testli property manbalaridan foydalanish bilan kontekst konfiguratsiyasi" bo'limida ko'ring.

`@DynamicPropertySource`

@DynamicPropertySource metod darajasidagi annotatsiya bo'lib, u integratsion test uchun yuklangan ApplicationContext muhiti uchun PropertySources ga qo'shiladigan dinamik propertylarni ro'yxatdan o'tkazish uchun ishlatiladi. Dinamik propertylar property qiymatlari avvaldan ma'lum bo'lmagan hollarda foydali bo'lib, masalan, propertylar tashqi resurs tomonidan boshqariladi, Testcontainers loyihasi tomonidan boshqariladigan konteynerlar holatidagi kabi.

Quyidagi misol bir dinamik property qanday ro'yxatdan o'tkazilishini ko'rsatadi:

Java

@ContextConfiguration
class MyIntegrationTests {
    static MyExternalServer server = // ...
    @DynamicPropertySource 
    static void dynamicProperties(DynamicPropertyRegistry registry) { 
        registry.add("server.port", server::getPort); 
    }
    // tests ...
}

Static metodni @DynamicPropertySource annotatsiyasi bilan belgilang.
DynamicPropertyRegistry argument sifatida qabul qilinadi.
Serverdan kechiktirilgan holda kutilayotgan dinamik server.port propertyni registratsiya qilamiz.

Kotlin

@ContextConfiguration
class MyIntegrationTests {
    companion object {
        @JvmStatic
        val server: MyExternalServer = // ...
        @DynamicPropertySource 
        @JvmStatic
        fun dynamicProperties(registry: DynamicPropertyRegistry) { 
            registry.add("server.port", server::getPort) 
        }
    }
    // tests ...
}

Static metodni @DynamicPropertySource annotatsiyasi bilan belgilang.
DynamicPropertyRegistry argument sifatida qabul qilinadi.
Serverdan kechiktirilgan holda kutilayotgan dinamik server.port propertyni registratsiya qilamiz.

Qo'shimcha ma'lumotlarni "Dinamik property manbalaridan foydalanib kontekst konfiguratsiyasi" bo'limida ko'ring.

`@DirtiesContext`

@DirtiesContext annotatsiyasi Spring dan kelgan asosiy ApplicationContext test bajarilganda "ifloslangan"ligini bildiradi (ya'ni, test uni qandaydir tarzda o'zgartirgan yoki buzgan - masalan, singleton bean holatini o'zgartirib) va uni yopish kerak. Agar ilova konteksti "iflos" deb belgilansa, u test tizimining keshidan olib tashlanadi va yopiladi. Natijada, asosiy Spring konteyneri har qanday keyingi test uchun qayta yig'iladi, unga shu bir xil konfiguratsiya metama'lumotlari kerak.

@DirtiesContext annotatsiyasini bir sinf yoki sinflar iyerarxiyasida sinf darajasida yoki metod darajasida ishlatishingiz mumkin. Bunday stsenariylarda ApplicationContext har qanday bunday annotatsiyali metoddan oldin yoki keyin, shuningdek, hozirgi test sinfi oldida yoki keyin "ifloslangan" deb belgilanadi, methodMode va classMode ni sozlaganingizga qarab.

Quyidagi misollar turli xil konfiguratsiya stsenariylari holatlarida kontekst "ifloslanishi" mumkin bo'lgan holatlar haqida tushuntirish beradi:

Agar sinfda BEFORE_CLASS sinf rejimi bilan e'lon qilingan bo'lsa, joriy test sinfi oldida.

Java

@DirtiesContext(classMode = BEFORE_CLASS) 
class FreshContextTests {
    // yangi Spring konteyner talab qilinadigan ba'zi testlar
}

Joriy test sinfi oldidagi "iflos" kontekst.

Kotlin

@DirtiesContext(classMode = BEFORE_CLASS) 
class FreshContextTests {
    // yangi Spring konteyner talab qilinadigan ba'zi testlar
}

Joriy test sinfi oldidagi "iflos" kontekst.

Agar sinfda e'lon qilingan bo'lsa, AFTER_CLASS sinf rejimi bilan (ya'ni, standart holdagi sinf rejimi) joriy test sinfi keyinida.

Java

@DirtiesContext 
class ContextDirtyingTests {
    // Spring konteynerini ifloslantiradigan ba'zi testlar
}

Joriy test sinfidagi "iflos" kontekst.

Kotlin

@DirtiesContext 
class ContextDirtyingTests {
    // Spring konteynerini ifloslantiradigan ba'zi testlar
}

Joriy test sinfidagi "iflos" kontekst.

Agar sinfda e'lon qilingan bo'lsa, har bir test metodidan joriy test sinfida BEFORE_EACH_TEST_METHOD sinf rejimi bilan

Java

@DirtiesContext(classMode = BEFORE_EACH_TEST_METHOD) 
class FreshContextTests {
    // yangi Spring konteyner talab qilinadigan ba'zi testlar
}

Har bir test metodidan oldin "iflos" kontekst.

Kotlin

@DirtiesContext(classMode = BEFORE_EACH_TEST_METHOD) 
class FreshContextTests {
    // yangi Spring konteyner talab qilinadigan ba'zi testlar
}

Har bir test metodidan oldin "iflos" kontekst.

Agar sinfda e'lon qilingan bo'lsa, har bir test metodidan joriy test sinfida AFTER_EACH_TEST_METHOD sinf rejimi bilan

Java

@DirtiesContext(classMode = AFTER_EACH_TEST_METHOD) 
class ContextDirtyingTests {
    // Spring konteynerini ifloslantiradigan ba'zi testlar
}

Har bir test metodidan keyin "iflos" kontekst.

Kotlin

@DirtiesContext(classMode = AFTER_EACH_TEST_METHOD) 
class ContextDirtyingTests {
    // Spring konteynerini ifloslantiradigan ba'zi testlar
}

Har bir test metodidan keyin "iflos" kontekst.

Agar metodda e'lon qilingan bo'lsa, BEFORE_METHOD metod rejimi bilan joriy test oldidan

Java

@DirtiesContext(methodMode = BEFORE_METHOD) 
@Test
void testProcessWhichRequiresFreshAppCtx() {
    // yangi Spring konteyner talab qilinadigan ba'zi kod
}

Joriy test metodidan oldin "iflos" kontekst.

Kotlin

@DirtiesContext(methodMode = BEFORE_METHOD) 
@Test
fun testProcessWhichRequiresFreshAppCtx() {
    // yangi Spring konteyner talab qilinadigan ba'zi kod
}

Joriy test metodidan oldin "iflos" kontekst.

Agar metodda e'lon qilingan bo'lsa, AFTER_METHOD metod rejimi bilan joriy test keyinida (ya'ni, standart holdagi metod rejimi).

Java

@DirtiesContext 
@Test
void testProcessWhichDirtiesAppCtx() {
    // Spring konteynerini ifloslantiradigan ba'zi kod
}

Joriy test metodidan keyin "iflos" kontekst.

Kotlin

@DirtiesContext 
@Test
fun testProcessWhichDirtiesAppCtx() {
    // Spring konteynerini ifloslantiradigan ba'zi kod
}

Joriy test metodidan keyin "iflos" kontekst.

Agar siz @DirtiesContext annotatsiyasini test konteksti iyerarxiyasining bir qismi sifatida @ContextHierarchy annotatsiyasi yordamida konfiguratsiya qilingan holda ishlatsangiz, bu jarayonni boshqarish uchun hierarchyMode bayrog'idan foydalanishingiz mumkin. Standart holda, kontekst keshini tozalash jarayoni haqiqiy test darajasidan tashqari barcha boshqa kontekstual iyerarxiyalarni ishga tushuvchi umumiy kontekst-ota bilan umumiy holatida to'liq qamrab olish algoritmi yordamida amalga oshiriladi. Ehtimoliy natijada, umumiy kontekst-ota iyerarxiyasidagi barcha ApplicationContext instansiyalari kontekst keshidan olib tashlanadi va yopiladi. Agar to'liq qamrab olish algoritmi ma'lum bir foydalanish holati uchun ortiqcha bo'lsa, quyidagi misolda ko'rsatilganidek, hozirgi darajadagi soddalashtirilgan algoritmni o'rnatishingiz mumkin.

Java

@ContextHierarchy({
    @ContextConfiguration("/parent-config.xml"),
    @ContextConfiguration("/child-config.xml")
})
class BaseTests {
    // sinfning tanasi...
}
class ExtendedTests extends BaseTests {
    @Test
    @DirtiesContext(hierarchyMode = CURRENT_LEVEL) 
    void test() {
        // ba'zi kod, bu qaysidir tarzda bolalar kontekstini ifloslantiradi
    }
}

Hozirgi daraja algoritmini ishlatamiz.

Kotlin

@ContextHierarchy(
    ContextConfiguration("/parent-config.xml"),
    ContextConfiguration("/child-config.xml"))
open class BaseTests {
    // sinfning tanasi...
}
class ExtendedTests : BaseTests() {
    @Test
    @DirtiesContext(hierarchyMode = CURRENT_LEVEL) 
    fun test() {
        // ba'zi kod, bu qaysidir tarzda bolalar kontekstini ifloslantiradi
    }
}

Hozirgi daraja algoritmini ishlatamiz.

Qo'shimcha ma'lumot va EXHAUSTIVE va CURRENT_LEVEL algoritmlari haqida "DirtiesContext.HierarchyMode" javadocni ko'ring.

`@TestExecutionListeners`

@TestExecutionListeners ma'lum bir test sinfi uchun, uning subklasslari va ichki sinflari uchun tinglovchilarni ro'yxatdan o'tkazish uchun ishlatiladi. Agar tinglovchilarni global ro'yxatdan o'tkazish kerak bo'lsa, uni TestExecutionListener konfiguratsiyasi bo'limida tasvirlangan avtomatik aniqlash mexanizmi orqali ro'yxatdan o'tkazishingiz kerak.

Quyidagi misol ikkita TestExecutionListener implementatsiyalarini qanday ro'yxatdan o'tkazishni ko'rsatadi:

Java

@ContextConfiguration
@TestExecutionListeners({CustomTestExecutionListener.class, AnotherTestExecutionListener.class}) 
class CustomTestExecutionListenerTests {
    // sinfning tanasi...
}

Ikkita TestExecutionListener implementatsiyalarini ro'yxatdan o'tkazamiz.

Kotlin

@ContextConfiguration
@TestExecutionListeners(CustomTestExecutionListener::class, AnotherTestExecutionListener::class) 
class CustomTestExecutionListenerTests {
    // sinfning tanasi...
}

Ikkita TestExecutionListener implementatsiyalarini ro'yxatdan o'tkazamiz.

Standart holda, @TestExecutionListeners annotatsiyasi superklasslar yoki qamrab oluvchi sinflar tomonidan tinglovchilarni meros qilib olishni qo'llab-quvvatlaydi. Misol va qo'shimcha ma'lumotlarni "Tartiblangan test sinf konfiguratsiyasi" bo'limida va @TestExecutionListeners annotatsiyasiga tegishli javadocda ko'ring. Agar siz TestExecutionListenerning standart implementatsiyalariga qaytishingiz kerak bo'lsa, "TestExecutionListener implementatsiyalarini ro'yxatdan o'tkazish" bo'limidagi eslatmani ko'ring.

`@RecordApplicationEvents`

@RecordApplicationEvents annotatsiyasi sinf darajasidagi annotatsiya bo'lib, Spring TestContext Frameworkga yagona test avtogorigu davomida ApplicationContextda chop etilgan barcha ilova hodisalarini yozib olishni buyuradi.

Yozilgan hodisalarga test doirasida ApplicationEvents API orqali kirish mumkin.

Ilova hodisalari haqida "Ilova hodisalari" va "Annotatsiya @RecordApplicationEvents" javadocni ko'rib chiqing.

`@Commit`

@Commit annotatsiyasi tranzaksiya tranzaktsion test metodidan keyin bajarilishi kerakligini bildiradi. @Rollback(false) annotatsiyasining yozilgan naqsh usuliga to'g'ridan-to'g'ri muqobil sifatida @Commitdan foydalanishingiz mumkin. @Rollback annotatsiyasiga o'xshash, @Commit annotatsiyasini sinf yoki metod darajasida e'lon qilishingiz mumkin.

Quyidagi misol @Commit annotatsiyasidan qanday foydalanishni ko'rsatadi:

Java

@Commit 
@Test
void testProcessWithoutRollback() {
    // ...
}

Test natijasini ma'lumotlar bazasida tasdiqlaymiz.

Kotlin

@Commit 
@Test
fun testProcessWithoutRollback() {
    // ...
}

Test natijasini ma'lumotlar bazasida tasdiqlaymiz.

`@Rollback`

@Rollback annotatsiyasi tranzaktsion test metodidan keyin tranzaktsiyani qayta tiklash kerakligini bildiradi. Agar true ga o'rnatilgan bo'lsa, tranzaktsiya qayta tiklanadi. Aks holda, tranzaktsiya bajariladi (shuningdek, @Commit ga qarang). Spring TestContext Framework uchun integratsion testlar uchun standart qayta tiklash qiymati true ga teng, hatto @Rollback annotatsiyasi aniq e'lon qilinmagan bo'lsa ham.

Agar @Rollback annotatsiyasi sinf darajasida e'lon qilingan bo'lsa, u test sinfi iyerarxiyasidagi barcha test metodlari uchun standart qayta tiklash semantikasini aniqlaydi. Agar @Rollback annotatsiyasi metod darajasida e'lon qilingan bo'lsa, u test metodi uchun qayta tiklash semantikasini aniqlaydi, ehtimol sinf darajasida @Rollback yoki @Commit annotatsiyasining semantikasini qayta o'rnatadi.

Quyidagi misolda test metodi natijasi qaytarilmaydi (ya'ni, natija ma'lumotlar bazasida tasdiqlanadi):

Java

@Rollback(false) 
@Test
void testProcessWithoutRollback() {
    // ...
}

Natijani qaytarmaymiz.

Kotlin

@Rollback(false) 
@Test
fun testProcessWithoutRollback() {
    // ...
}

Natijani qaytarmaymiz.

`@BeforeTransaction`

@BeforeTransaction annotatsiyasi Spring @Transactional anotatsiyasi orqali o'tkazilishi uchun konfiguratsiya qilingan test metodi oldidan bajarilishi kerak bo'lgan anotatsiyalangan void metodni bildiradi. @BeforeTransaction annotatsiyasi bilan belgilangan metodlar public bo'lishi shart emas va Java 8 asosidagi standart realizatsiyaga ega interfeys metodlarida e'lon qilinishi mumkin.

Quyidagi misol @BeforeTransaction annotatsiyasidan qanday foydalanishni ko'rsatadi:

Java

@BeforeTransaction 
void beforeTransaction() {
    // tranzaktsiya boshlanishidan oldin bajarilishi kerak bo'lgan mantiq
}

Ushbu metodni tranzaktsiyadan oldin bajaramiz.

Kotlin

@BeforeTransaction 
fun beforeTransaction() {
     // tranzaktsiya boshlanishidan oldin bajarilishi kerak bo'lgan mantiq
}

Ushbu metodni tranzaktsiy

Oldingi Oldingi dars

Keyingisi Keyingi dars

Izohlar

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION