Reaktsiya tarkibiy qismlarini sinashning to'g'ri yo'li

Reaktsiya komponentlarini sinab ko'rishning "to'g'ri" usuli haqida hozirda juda ko'p chalkashliklar mavjud. O'zingizning barcha testlaringizni qo'l bilan yozishingiz kerak yoki shunchaki suratlardan yoki ikkalasidan ikkitasini ishlatishingiz kerakmi? Siz rekvizitlarni sinab ko'rishingiz kerakmi? Davlatmi? Uslublar / maket?

Menimcha, bitta "to'g'ri" yo'l yo'q, lekin men sizlarga aytib berishni istagan juda yaxshi shakllar va maslahatlar topdim.

Fevral 2019ni yangilash: Ushbu postda reaktsiya tarkibiy qismlarini sinovdan o'tkazish usuli tasvirlangan. Vaqt o'tishi bilan, integratsiya sinovlaridan birlik sinovlariga qaraganda ko'proq qiymatga ega ekanligimni aniqladim, shuning uchun men shaxsan ushbu usulni qo'llamayman.

Agar siz React dasturingiz uchun integratsiya testlarini yozmoqchi bo'lsangiz, men hozir ishlatadigan Cypress-ni tavsiya qilaman.

Shunga qaramay, siz ushbu xabarni hali ham foydali deb topishingiz mumkin - ushbu postda tasvirlangan usul haqida o'ylab ko'rsangiz, tarkibiy qismlarni qayta ishlatiladigan aniq shartnomalar bilan yozishingizga yordam beradi.

Umumiy ma'lumot: Biz sinovdan o'tkazadigan ilova

Aytaylik, siz qulflash ekrani kabi bo'lgan LockScreen komponentini sinab ko'rmoqchisiz. Bu:

  • Joriy vaqtni ko'rsatadi
  • Foydalanuvchi tomonidan belgilangan xabarni ko'rsatishi mumkin
  • Foydalanuvchi tomonidan belgilangan fon rasmini namoyish qilishi mumkin
  • Pastki qismida slaydni ochish uchun vidjet mavjud

Bu quyidagicha ko'rinadi:

Siz buni bu erda sinab ko'rishingiz va GitHub-dagi kodni ko'rishingiz mumkin.

Bu erda yuqori darajadagi ilova komponentlari uchun kod mavjud:

Ko'rib turganingizdek, LockScreen uchta rekvizitni qabul qiladi: wallpaperPath, userInfoMessage va blokirovka qilingan.

LockScreen uchun kod:

LockScreen boshqa bir nechta tarkibiy qismlarni o'z ichiga oladi, ammo biz hozirda LockScreenni sinab ko'rayotganimiz sababli, e'tiboringizni hozirga qarataylik.

Komponent shartnomalari

LockScreen-ni sinab ko'rish uchun avval uning Shartnomasi nima ekanligini tushunishingiz kerak. Komponent shartnomasini tushunish React komponentini sinashning eng muhim qismidir. Shartnoma sizning tarkibiy qismingizning kutilayotgan xatti-harakatlarini va undan foydalanish bo'yicha qanday taxminlar oqilona ekanligini belgilaydi. Aniq shartnoma bo'lmasa, sizning komponentingizni tushunish qiyin bo'lishi mumkin. Yozish testlari - bu sizning komponentingiz shartnomasini rasmiy ravishda aniqlashning ajoyib usuli.

Reactning har bir tarkibiy qismi hech bo'lmaganda uning shartnomasini aniqlashga hissa qo'shadigan bitta narsaga ega:

  • U nimani aks ettiradi (hech narsa bo'lmasligi mumkin)

Bundan tashqari, tarkibiy shartnomalarning aksariyati quyidagilarga ta'sir qiladi:

  • Komponent qabul qiladi
  • Komponentning holati (agar mavjud bo'lsa)
  • Foydalanuvchi u bilan o'zaro aloqada bo'lganda nima ishlaydi (bosish, tortish, klaviatura orqali kiritish va hk)

Komponent shartnomalariga ta'sir ko'rsatadigan kamroq tarqalgan narsalar:

  • Tarkib tarkibiy qism ichida ko'rsatilgan
  • O'zingizning misolingizdagi usullarni chaqirganda komponent nima qiladi (public ref interfeysi)
  • Komponentlarning hayot aylanishining bir qismi sifatida yuzaga keladigan nojo'ya ta'sirlar (komponentDidMount, komponentWillUnmount va boshqalar)

Komponentingiz shartnomasini topish uchun o'zingizga quyidagi savollarni bering:

  • Mening tarkibiy qismim nimani anglatadi?
  • Mening tarkibiy qismim har xil sharoitlarda turli xil narsalarni namoyish etadimi?
  • Men funktsiyani prop sifatida o'tkazganimda, mening tarkibiy qismim uni nima uchun ishlatadi? Uni chaqiradimi yoki shunchaki boshqa tarkibiy qismga beradimi? Agar u qo'ng'iroq qilsa, uni nima bilan chaqiradi?
  • Foydalanuvchi mening komponentim bilan aloqa qilganda nima bo'ladi?

LockScreen-ning shartnomasini topish

LockScreen-ning ishlash usulini ko'rib chiqamiz va uning xatti-harakatlari farq qilishi mumkin bo'lgan joylarga izoh qo'shamiz. Agar biz uchliklarni qidirib topsak va gaplar bizning kalitimiz bo'lsa. Bu bizga shartnomadagi tafovutlarni topishga yordam beradi.

Biz LockScreen shartnomasini tavsiflovchi uchta cheklovni bilib oldik:

  • Agar devor qog'ozi chizig'i uzatilsa, u holda tarkibiy qism taqdim etadigan eng tashqi ajratish paneli urni (...) ga o'ralgan fon rasmi CSS xususiyatiga ega bo'lishi kerak.
  • Agar userInfoMessage prop uzatilsa, uni bolalar singari TopOverlay-ga o'tkazish kerak, uni ma'lum bir chizilgan uslublar to'plami bilan ko'rsatish kerak.
  • Agar userInfoMessage prop o'tkazilmasa, hech qanday TopOverlay ko'rsatilmasligi kerak.

Shartnomaning har doim ham to'g'ri bo'lgan ba'zi cheklovlarini topishingiz mumkin:

  • Har doim hamma narsa mavjud bo'lgan div har doim ko'rsatiladi. Ichki uslublarning ma'lum bir to'plamiga ega.
  • ClockDisplay har doim ko'rsatiladi. Hech qanday rekvizitni olmaydi.
  • SlideToUnlock har doim ko'rsatiladi. Belgilangan yoki aniqlanmaganligidan qat'i nazar, u onSlide prop sifatida o'tgan qabul qilingan blok qiymatini oladi.

Komponentning tavsiflari, shuningdek, uning shartnomasi haqida ma'lumot izlash uchun yaxshi joy. Yana bir nechta cheklovlarni payqadim:

  • wallpaperPath satr bo'lishi kutilmoqda va ixtiyoriy.
  • userInfoMessage satr bo'lishi kutilmoqda va ixtiyoriy.
  • onUnlock funksiyasi bo'lishi kutilmoqda va ixtiyoriy.

Bu bizning tarkibiy shartnomamiz uchun yaxshi boshlang'ich nuqtadir. Ushbu komponent shartnomasida ko'proq cheklovlar bo'lishi mumkin va ishlab chiqarish kodida siz iloji boricha ko'proq odamni topishni xohlaysiz, ammo bu misolning maqsadlari uchun shunchaki ishlash kerak. Agar qo'shimcha cheklovlarni aniqlasangiz, har doim testlarni har doim qo'shishingiz mumkin.

Sinovga nima arziydi?

Keling, topilgan shartnomani ko'rib chiqaylik:

  • wallpaperPath satr bo'lishi kutilmoqda va ixtiyoriy.
  • userInfoMessage satr bo'lishi kutilmoqda va ixtiyoriy.
  • onUnlock funksiyasi bo'lishi kutilmoqda va ixtiyoriy.
  • Har doim hamma narsa mavjud bo'lgan div har doim ko'rsatiladi. Ichki uslublarning ma'lum bir to'plamiga ega.
  • ClockDisplay har doim ko'rsatiladi. Hech qanday rekvizitni olmaydi.
  • SlideToUnlock har doim ko'rsatiladi. Belgilangan yoki aniqlanmaganligidan qat'i nazar, u onSlide prop sifatida qabul qilingan blokirovkaning qiymatini oladi.
  • Agar devor qog'ozi chizig'i o'tkazilsa, u holda tarkibiy qism taqdim etadigan eng tashqi ajratish divasi o'zining ichki uslubida fon-image css xususiyatiga ega bo'lishi kerak, u WallPath qiymatini URL manziliga (...) o'ralgan holda o'rnatiladi.
  • Agar userInfoMessage prop versiyasi bo'lsa, u bolalar singari TopOverlay-ga topshirilishi kerak, uni ma'lum bir chizilgan uslublar to'plami bilan ko'rsatish kerak.
  • Agar userInfoMessage prop o'tkazilmasa, hech qanday TopOverlay ko'rsatilmasligi kerak.

Ushbu cheklovlarning ba'zilari sinab ko'rishga arziydi, boshqalari esa yo'q. Bu erda men biron bir narsani sinab ko'rishga yaramasligini aniqlash uchun uchta qoidadan foydalanaman:

  1. Sinov aniq dastur kodini nusxalashga majbur bo'ladimi? Bu uni mo'rt qiladi.
  2. Sinovda tasdiqlash kutubxona kodi bilan qoplangan (va javobgarlik) xatti-harakatlarning nusxasini takrorlaydimi?
  3. O'zga odamning nuqtai nazari bo'yicha, bu tafsilot muhimmi yoki bu faqat ichki tashvishmi? Ushbu ichki tafsilotning ta'sirini faqat komponentning umumiy API yordamida tasvirlash mumkinmi?

Bular faqat bosh barmog'ingizning qoidalaridir, shuning uchun ularni ishlatish qiyin, chunki biror narsani sinab ko'rmaslik uchun oqlanmang. Ko'pincha, sinovdan o'tish qiyin bo'lib tuyuladigan narsalar sinov uchun eng muhimdir, chunki sinov ostidagi kod dasturning qolgan qismi haqida ko'plab taxminlarni keltirib chiqaradi.

Keling, qiyinchiliklarimizni boshdan kechiraylik va ushbu qoidalarni sinab ko'rish kerakligini aniqlash uchun foydalaning. Mana birinchi uchta:

  • wallpaperPath satr bo'lishi kutilmoqda va ixtiyoriy.
  • userInfoMessage satr bo'lishi kutilmoqda va ixtiyoriy.
  • onUnlock funksiyasi bo'lishi kutilmoqda va ixtiyoriy.

Ushbu cheklovlar React's PropTypes mexanizmini tashvishga soladi, shuning uchun prop turlari atrofida testlarni yozish # 2 qoidasi bajarilmaydi (kutubxona kodi bilan qoplangan). Shunday qilib, men prop turlarini sinovdan o'tkazmayman. Sinovlar ko'pincha hujjatlar bilan birlashtirilganligi sababli, agar dastur kodi kutilgan turlarni juda yaxshi hujjatlashtirmasa, №2 qoidaga mos kelmaydigan narsani sinab ko'rishga qaror qilishim mumkin, ammo propTypes allaqachon yoqimli va inson tomonidan o'qilishi mumkin.

Quyidagi cheklov:

  • Har doim hamma narsa mavjud bo'lgan div har doim ko'rsatiladi. Ichki uslublarning ma'lum bir to'plamiga ega.

Buni uchta cheklovga bo'lish mumkin:

  • Div har doim ko'rsatiladi.
  • Taqdim etilgan div, boshqa ko'rinadigan narsalarga ega.
  • Ko'rsatilgan div ma'lum bir ichki uslublarning to'plamiga ega.

Biz buni buzib tashlagan dastlabki ikkita qiyinchiliklar bizning qoidalarimizni buzmaydi, shuning uchun biz ularni sinab ko'ramiz. Biroq, uchinchisini ko'rib chiqaylik.

Boshqa cheklov bilan qoplangan fon-rasm xususiyatini e'tiborsiz qoldirib, o'rash bo'limi quyidagi uslublarga ega:

balandligi: "100%",
displey: "moslashuvchan",
justifyContent: "bo'sh joy orasidagi",
flexDirection: "ustun",
fon rangi: "qora",
fon holati: "markaz",
backgroundSize: "qopqoq",

Agar biz ushbu uslublar divda ekanligi haqida test yozgan bo'lsak, unda foydali ma'lumotlar berish uchun har bir uslubning qiymatini aniq sinovdan o'tkazishimiz kerak. Shunday qilib, bizning tasdiqlarimiz quyidagicha bo'lishi mumkin:

  • Bog'laydigan div balandligi uslubi xususiyatiga ega bo'lishi kerak 100%
  • Bog'lab qo'yish moslamasi Flex ekranining uslubi xususiyatiga ega bo'lishi kerak
  • … Va har bir uslub mulki uchun

Ushbu testni qisqa tutish uchun biz toMatchObject kabi biror narsadan foydalansak ham, dastur kodidagi bir xil uslublarni takrorlashimiz mumkin va mo'rtroq bo'lishimiz mumkin. Agar biz boshqa uslubni qo'shsak, testimizda aniq bir xil kodni qo'yishimiz kerak edi. Agar biz uslubni buzgan bo'lsak, uni sinab ko'rishimiz kerak, garchi komponentning xatti-harakati o'zgarmagan bo'lsa ham. Shu sababli, ushbu cheklov №1 qoidaga mos kelmaydi (dastur kodi takrorlanadi; mo'rt). Shuning uchun, ichki ish uslublarini sinovdan o'tkazmayman, agar ular ish vaqtida o'zgarmasa.

Ko'pincha, agar siz "u nima qilsa, shuni bajaradi" yoki "dastur kodida ko'paytiriladigan aynan shunday" degan testni yozayotgan bo'lsangiz, unda test keraksiz yoki juda keng bo'ladi.

Keyingi ikkita cheklovlar:

  • ClockDisplay har doim ko'rsatiladi. Hech qanday rekvizitni olmaydi.
  • SlideToUnlock har doim ko'rsatiladi. Belgilangan yoki aniqlanmaganligidan qat'i nazar, u onSlide prop sifatida o'tgan qabul qilingan blok qiymatini oladi.

Bularni quyidagilarga bo'lish mumkin:

  • ClockDisplay har doim ko'rsatiladi.
  • Taqdim etilgan ClockDisplay hech qanday rekvizitlarni qabul qilmaydi.
  • SlideToUnlock har doim ko'rsatiladi.
  • O'chirilgan qulflangan blok aniqlanganda, SlideToUnlock ushbu prop qiymatini onSlide prop sifatida oladi.
  • Agar qulfdan chiqarilgan qulf bloki aniqlanmagan bo'lsa, ko'rsatilgan SlideToUnlock-ning onSlide propi ham aniqlanmagan bo'lishi kerak.

Ushbu cheklovlar ikki toifaga bo'linadi: "Ba'zi bir kompozitsion komponentlar ko'rsatiladi" va "taqdim etilgan komponent ushbu rekvizitlarni oladi". Ikkalasi ham sinab ko'rish uchun juda muhimdir, chunki ular sizning tarkibiy qismingiz boshqa tarkibiy qismlar bilan qanday ta'sir qilishini tasvirlaydi. Biz ushbu cheklovlarning barchasini sinovdan o'tkazamiz.

Keyingi cheklash:

  • Agar devor qog'ozi chizig'i o'tkazilsa, u holda tarkibiy qism taqdim etadigan eng tashqi ajratish divasi o'zining ichki uslubida fon-image css xususiyatiga ega bo'lishi kerak, u WallPath qiymatini URL manziliga (...) o'ralgan holda o'rnatiladi.

Siz bu deb o'ylashingiz mumkin, chunki bu ichki uslub, uni sinab ko'rishimiz shart emas. Biroq, fon rasmining qiymati wallpaperPath prop asosida o'zgarishi mumkinligi sababli uni sinab ko'rish kerak. Agar biz uni sinab ko'rmagan bo'lsak, unda ushbu komponentning ommaviy interfeysining bir qismi bo'lgan wallpaperPath prop-ning ta'siri haqida hech qanday sinov bo'lmaydi. Siz doimo umumiy interfeysingizni sinab ko'rishingiz kerak.

Oxirgi ikkita cheklovlar:

  • Agar userInfoMessage prop versiyasi bo'lsa, u bolalar singari TopOverlay-ga topshirilishi kerak, uni ma'lum bir chizilgan uslublar to'plami bilan ko'rsatish kerak.
  • Agar userInfoMessage prop o'tkazilmasa, hech qanday TopOverlay ko'rsatilmasligi kerak.

Bularni quyidagilarga bo'lish mumkin:

  • Agar userInfoMessage prop uzatilsa, TopOverlay ko'rsatilishi kerak.
  • Agar userInfoMessage prop uzatilsa, uning qiymati bolalarga TopOverlay-ga ko'rsatilishi kerak.
  • Agar userInfoMessage prop uzatilsa, namoyish etilgan TopOverlay ma'lum bir chizilgan stil bilan ko'rsatilishi kerak.
  • Agar userInfoMessage prop o'tkazilmasa, hech qanday TopOverlay ko'rsatilmasligi kerak.

Birinchi va to'rtinchi cheklovlar (TopOverlay ko'rsatilmasligi kerak / bo'lmasligi kerak) bizning ko'rsatgan narsalarimizni tavsiflaydi, shuning uchun biz ularni sinab ko'ramiz.

Ikkinchi cheklov, TopOverlay userInfoMessage qiymatiga qarab ma'lum bir rekvizitni olishini tasdiqlaydi. Berilgan tarkibiy qismlarni olgan rekvizitlar atrofida testlarni yozish juda muhim, shuning uchun biz uni sinab ko'ramiz.

Uchinchi cheklov TopOverlay ma'lum bir rekvizitni qabul qilishini tasdiqlaydi, shuning uchun siz uni sinab ko'rishimiz kerak deb o'ylashingiz mumkin. Biroq, bu zarb faqat ba'zi ichki uslublardir. Rekvizitlar o'tganligini tasdiqlash juda muhim, ammo ichki uslublar haqida ishonch hosil qilish mo'rt va amaliy kodni nusxasini ko'chiradi (№1 qoidalar bajarilmaydi). O'tkazib yuborilgan rekvizitlarni sinash juda muhim bo'lgani uchun, uni faqat # 1 qoidaga qarab sinov qilish kerakligi aniq emas; Yaxshiyamki, men 3-qoidaga egaman. Eslatma sifatida:

O'zga odamning nuqtai nazari bo'yicha, bu tafsilot muhimmi yoki bu faqat ichki tashvishmi? Ushbu ichki tafsilotning ta'sirini faqat komponentning umumiy API yordamida tasvirlash mumkinmi?

Komponent testlarini yozayotganda, men faqat mumkin bo'lgan joyda komponentning ommaviy API-ni sinovdan o'tkazaman (shu jumladan, API-ning yon ta'siri). Ushbu komponentning aniq tartibiga ushbu komponentning umumiy API ta'sir ko'rsatmaydi; bu CSS dvigateliga tegishli. Shu sababli, ushbu cheklov №3 qoidaga mos kelmaydi. U # 1 va 3-qoidaga mos kelmagani uchun, biz ushbu cheklovni sinovdan o'tkazmaymiz, garchi u TopOverlay odatda muhim bo'lgan rekvizitni olishini tekshirsa ham.

Ushbu oxirgi cheklovni sinab ko'rish kerakmi yoki yo'qmi, aniqlash qiyin edi. Oxir-oqibat, qaysi qismlarni sinash muhimligini o'zingiz hal qilasiz; men foydalanadigan bosh barmog'ingizning ushbu qoidalari faqat ko'rsatmalardir.

Endi biz barcha qiyinchiliklarimizni boshdan kechirdik va kimni sinovdan o'tkazishni bilamiz. Mana ular:

  • Div har doim ko'rsatiladi.
  • Taqdim etilgan div, boshqa ko'rinadigan narsalarga ega.
  • ClockDisplay har doim ko'rsatiladi.
  • Taqdim etilgan ClockDisplay hech qanday rekvizitlarni qabul qilmaydi.
  • SlideToUnlock har doim ko'rsatiladi.
  • O'chirilgan qulflangan blok aniqlanganda, SlideToUnlock ushbu prop qiymatini onSlide prop sifatida oladi.
  • Agar qulfdan chiqarilgan qulf bloki aniqlanmagan bo'lsa, ko'rsatilgan SlideToUnlock-ning onSlide propi ham aniqlanmagan bo'lishi kerak.
  • Agar devor qog'ozi chizig'i o'tkazilsa, u holda tarkibiy qism taqdim etadigan eng tashqi ajratish divasi o'zining ichki uslubida fon-image css xususiyatiga ega bo'lishi kerak, u WallPath qiymatini URL manziliga (...) o'ralgan holda o'rnatiladi.
  • Agar userInfoMessage prop uzatilsa, TopOverlay ko'rsatilishi kerak.
  • Agar userInfoMessage prop uzatilsa, uning qiymati bolalarga TopOverlay-ga ko'rsatilishi kerak.
  • Agar userInfoMessage prop o'tkazilmasa, hech qanday TopOverlay ko'rsatilmasligi kerak.

Cheklovlarimizni o'rganib chiqib, ularni sinchkovlik bilan tekshirib, biz ularning ko'pchiligini kichikroq va kichikroq cheklovlarga ajratdik. Bu ajoyib! Bu bizning sinov kodimizni yozishni osonlashtiradi.

Ba'zi sinov qozonini o'rnatish

Keling, ushbu komponent uchun sinovni boshlaylik. Men testlarimda Jestni ferment bilan ishlataman. Jest React bilan juda yaxshi ishlaydi va shuningdek, uni yaratish uchun reaksiya dasturini yaratgan ilovalar tarkibiga kiritilgan sinov yuguruvchisi hisoblanadi. Ferment - bu tugun ham, brauzerda ham ishlaydigan etuk reaktiv sinov kutubxonasi.

Men testlarimda Jest va fermentdan foydalansam ham, siz bu erda tushunchalarni deyarli har qanday sinov konfiguratsiyasiga qo'llashingiz mumkin.

Bu juda ko'p qozonxona. Bu erda nimani o'rnatganimni tushuntirib beray.

  • Men "rekvizitlar" va "mountedLockScreen" uchun bog'lovchilarni yarataman, shunda bu o'zgaruvchilar ta'riflash funktsiyasi doirasidagi hamma narsaga ega bo'ladi.
  • Men LockScreen funksiyasini yarataman, u tasvirlash funktsiyasining istalgan joyida mavjud, u LockScreen o'zgaruvchisidan foydalanib, LockScreen-ni joriy rekvizitlar bilan o'rnatish yoki allaqachon o'rnatilganini qaytarish uchun ishlatiladi. Ushbu funktsiya ReactWrapper fermentini qaytaradi. Biz uni har bir sinovda ishlatamiz.
  • Men har bir sinovdan oldin rekvizitlarni va o'rnatilganLockScreen parametrlarini o'zgartiradigan beforeEach o'rnatdim. Aks holda, bitta testdan boshqa holatga o'tish mumkin. Belgilanmagan joyga o'rnatilganLockScreen-ni o'rnatish orqali, keyingi sinov ishlaganda, agar u LockScreen-ni chaqirsa, yangi LockScreen joriy rekvizitlar bilan o'rnatiladi.

Ushbu qozonxona komponentni sinab ko'rish uchun juda ko'p narsa bo'lib tuyulishi mumkin, ammo bu bizning tarkibiy qismimizni o'rnatishdan oldin rekvizitlarimizni asta-sekin yig'ish imkonini beradi, bu bizning sinovlarimizni quruq saqlashga yordam beradi. Men uni barcha tarkibiy sinovlarim uchun ishlataman va umid qilamanki, sizga foydali bo'ladi; uning foydali tomonlari biz sinov ishlarini yozishda aniqroq bo'ladi.

Sinovlarni yozish!

Keling, cheklovlar ro'yxatimizni ko'rib chiqaylik va har biri uchun sinov qo'shamiz. Har bir test shunday joylashtiriladiki, // u erda joylashtirilishi mumkin bo'lgan barcha testlar shu erda qozonxonada sharhlanadi.

  • Div har doim ko'rsatiladi.
  • Taqdim etilgan div, boshqa ko'rinadigan narsalarga ega.
  • ClockDisplay har doim ko'rsatiladi.
  • Taqdim etilgan ClockDisplay hech qanday rekvizitlarni qabul qilmaydi.
  • SlideToUnlock har doim ko'rsatiladi.

Shu paytgacha barcha cheklovlar har doim ham haqiqat bo'lib kelgan, shuning uchun ularning sinovlari sodda yozilgan. Ammo qolgan cheklovlar "Agar" va "Qachon" kabi so'zlar bilan boshlanadi. Bular shartli ravishda haqiqat va shuning uchun biz ularni sinab ko'rish uchunEEach bilan birga tasvirlaymiz. Bu erda biz ilgari yozgan barcha sinov qozonlari foydalidir.

  • O'chirilgan qulflangan blok aniqlanganda, SlideToUnlock ushbu prop qiymatini onSlide prop sifatida oladi.
  • Agar qulfdan chiqarilgan qulf bloki aniqlanmagan bo'lsa, ko'rsatilgan SlideToUnlock-ning onSlide propi ham aniqlanmagan bo'lishi kerak.

Agar biz faqat ma'lum bir sharoitda sodir bo'ladigan xatti-harakatlarni tasvirlashimiz kerak bo'lsa, biz o'sha holatni tasvirlashimiz mumkin va keyin ushbu holatni belgilash uchun avval tasvirlangan ichidaEEach-dan foydalanishimiz mumkin.

  • Agar devor qog'ozi chizig'i uzatilsa, u holda tarkibiy qism taqdim etadigan eng tashqi ajratish paneli urni (...) ga o'ralgan fon rasmi CSS xususiyatiga ega bo'lishi kerak.
  • Agar userInfoMessage prop uzatilsa, TopOverlay ko'rsatilishi kerak.
  • Agar userInfoMessage prop uzatilsa, uning qiymati bolalarga TopOverlay-ga ko'rsatilishi kerak.
  • Agar userInfoMessage prop o'tkazilmasa, hech qanday TopOverlay ko'rsatilmasligi kerak.

Bu bizning barcha cheklovlarimiz! Siz sinovning yakuniy faylini bu erda ko'rishingiz mumkin.

"Mening ishim emas"

Maqolaning boshidagi animatsion gif-ga qaraganingizda, siz bizning sinov ishlari quyidagicha yakunlanishini kutgandirsiz:

  • Foydalanuvchi slaydni ochish uchun tutqichni o'ng tomonga siljitganda, qulfni ochishga qayta qo'ng'iroq qilish chaqiriladi
  • Agar foydalanuvchi slaydni ochish uchun tutqichni yon tomonga siljitsa va uni qo'yib yuborsa, dastak asl holatiga qaytariladi
  • Ekranning yuqorisidagi soat har doim joriy vaqtni ko'rsatishi kerak

Bu sezgi tabiiydir. Ilova nuqtai nazaridan, bu eng muhim xususiyatlar.

Ammo, biz ushbu biron bir funktsionallik uchun yozma testlarni tugatmadik. Nima uchun? Ular LockScreen-ning tashvishi emas edi.

Reakt tarkibiy qismlari qayta ishlatiladigan birliklar bo'lganligi sababli, birlik sinovlari ular uchun tabiiydir. Va jihozni sinovdan o'tkazayotganda, siz faqat sizning haqiqiy birlik nimaga e'tibor berishini sinab ko'rishingiz kerak. React komponentlarini sinovdan o'tkazishda daraxtlarni o'rmondan ko'ra ko'rish yaxshidir.

Bu erda React tarkibiy qismlarining xavotirlari ko'rsatilgan qulay cheat varaqasi:

  • Men olgan rekvizitlar bilan nima qilishim kerak?
  • Qanday tarkibiy qismlarni namoyish qilaman? Ushbu tarkibiy qismlarga nimani beraman?
  • Hech qachon biron bir narsani ushlab turamanmi? Agar shunday bo'lsa, men yangi rekvizit olayotganda uni bekor qilamanmi? Shtat holatini qachon yangilayman?
  • Agar foydalanuvchi men bilan aloqada bo'lsa yoki bola komponenti men unga o'tgan qo'ng'iroqni qaytarsa, men nima qilaman?
  • O'rnatilganimda biron bir narsa bo'ladimi? Meni yechish paytida?

Yuqorida tavsiflangan xususiyatlar SlideToUnlock va ClockDisplay bilan bog'liq, shuning uchun bu xususiyatlar atrofidagi testlar shu tarkibiy qismlar uchun testlarda o'tkaziladi.

Xulosa

Umid qilamanki, ushbu usullar sizga o'zingizni React komponentlarini sinab ko'rishga yordam beradi. Xulosa qilish uchun:

  • Avval Komponent shartnomangizni toping
  • Qaysi cheklovlar sinab ko'rishga loyiq va qaysi biri yo'qligini aniqlang
  • Prop turlari sinab ko'rishga loyiq emas
  • Ichki uslublar odatda sinab ko'rishga loyiq emas
  • Sinab ko'rish uchun siz taqdim etadigan tarkibiy qismlar va ularni taqdim etgan narsalar muhimdir
  • Sizning tarkibiy qismingizga tegishli bo'lmagan narsalarni sinab ko'rmang

Agar siz ushbu xabarga rozi bo'lmasangiz yoki foydali deb hisoblasangiz, men sizdan twitter orqali eshitishni istayman. Kelinglar, birgalikda reaktsiya komponentlarini qanday sinashni bilib olaylik!

Ushbu maqola barcha huquqlar bilan himoyalangan bo'lsa ham, ushbu maqoladagi barcha kod namunalari GitHub-dagi manba omborida joylashgan MIT litsenziyasi bo'yicha mavjud.