Bismillah
Assalom alaykum!
Taxminiy o'qish vaqti: ~3 daqiqa
Code coverage bu dasturiy ta'minotning qanchalik darajada testlanganligini ko'rsatuvchi o'lchov hisoblanadi ya'ni har bir qator kodning test bilan tekshirilgan yoki tekshirilmaganligini ko'rsatib beradi. Umuman olganda dastur qanchalik ko'p testlar bilan qoplangan bo'lsa uning shuncha xavfsiz ekanligini bildiradi, eng kamida nazariyada. Lekin kodning to'liq ya'ni 100%
testlar bilan qamrab olish qanchalik foydali, unga ketgan vaqtga o'zi arziydimi? 100% coverage
quloqqa chiroyli eshitiladiyu ammo amaliyotda bu unchalik ham yaxshi ko'rsatgich emas.
Quyida 100% lik code coverage
ga (test bilan qoplanganlik) intilish bilan bog'liq muammolarni ko'rib chiqamiz:
- o'ta yuqori darajali
code coverage
dasturchilarga soxta xavfsizlik xissiyotini beradi. Chunki testlarnirun
qilish jarayonida har bir qatorning testlangani degani bu hali har bir qatorning o'z vazifasini to'g'ri bajarishini tasdiqlangani degani emas. 100% tasdiqlangan kod bu umumanbug
larsiz kod degani, bu esa amaliy imkonsiz bo'lgan narsa. Xatolar doim bo'ladi, asl maqsad ularni sonini iloji boricha kamaytirish va ularning xavflilik darajasini iloji boricha tushirishdir. - dasturning ba'zi imkoniyatlarini (
feature
) test qilish ancha mashaqqatli, masalan browserda fayllarni yuklash yokidrag-and-drop
. Har bir test foydalanuvchilar nuqtai-nazaridan kelib chiqib yozilishi kerak ya'ni testlarimiz foydalanuvchi dasturning muayyan imkoniyatini qanday ishlatsa uni shunday shaklda o'zida aks ettirishi kerak (e.g.button
elementiniloading
yokidisabled
holatiniredux
yokiuseState
da saqlayotganimiz foydalanuvchi uchun muhimmas (bilishi kerak ham emas), unga buttondagi visual o'zgarishni ko'rish muhim). Lekin bu holatda odatda ko'plabmock
lar ishlatamiz,component
ning ichki mexanizmlarini testlarga aralashtirishga majbur bo'lamiz va oxirida esa testlarimiz umuman boshqa shaklga aylanib qoladi va juda ko'p vaqt foydasi kam bo'lgan va o'zgarishlarga chidamsiz bo'lgan testlarga ketib qoladi. Bu esa testlashda "anti-pattern"dir 🚫. Ushbu maqolada Kent C. Dodds buni juda ajoyib qilib tushuntirgan.
mocking odatda unit testlarda ishlatiladi. Qisqa qilib aytganda,
mocking
bu real obyektlarni vazifasi/funksiyasini bajaruvchi soxta obyektni yaratish. Undan asosiy ko'zlangan maqsad esa testlanayotgan obyektning boshqa obyeklarga nisbatan bog'liqligini iloji boricha kamaytirish ya'nidependency
lardan holi ixotalangan muhit yaratish.anti-pattern: bu dasturiy ta'minot ishlab chiqishda (ba'zi boshqa sohalarda ham) ko'p takrorlanadigan muammolarga samarasiz va oqibatda yaxshi natijalarga olib kelmaydigan yechimdir (lekin ishlaydigan). Sodda misol:
- yaxshi "pattern" kodning takrorlanuvchi qismini alohida funksiyaga olib kerak paytda qayta ishlatish (
code-reuse
)- "anti-pattern" xuddi shu muammo uchun har safar
copy-paste
ishlatish.
Ko'p dasturchilarning tajribalaridan kelib chiqadigan bo'lsak, odatda ~100%
lik code coverage
2 ta holatdagina foydali:
- kutubxonalarda (
library
), tasodifiybreaking change
💥 lardan saqlanish juda ham muhim. Chunki bunday kutubxonalarni odatda minglagan yoki hatto millionlagan dasturchilar ishlatatishi mumkin (log4j eslang). - va
open source
ya'ni ochiq kodli proyektlarda, chunki bunday proyektlardacontributor
larning ko'pgina qismi proyektni arxitekturasi bilan to'liqligicha tanish bo'lishmaydi.
breaking change bu kutubxonaning yoki har qanday dasturiy ta'minotning (
REST API
,SDK
,UI Toolkit
...) biron qismidagi o'zgarish unga bog'liq bo'lgan tizimning boshqa qismlariga ham ta'sir qilishi (to'liq yoki qisman ishdan chiqarish) mumkin bo'lgan o'zgarishdir. Odatda bunday o'zgarishlar dasturiy ta'minot (DT) foydalanuvchilariga (bu holatda dasturchilar) oldindan o'sha DTning rasmiy websayti yoki boshqa yo'llar orqali bildiriladi (bildirilishi zarur ham).
Xo'sh unda o'rta yo'l qayerda, buni aniq aytish qiyin, odatda bu muayyan dasturiy ta'minotga, jamoaga va undagi qabul qilingan prioritetlarga bog'liq, o'rtacha dastur kodining 60-70
foizi testlar bilan qoplanganligi bu yaxshi ko'rsatgich (lekin bu meni subyektiv fikrim).
Code coverage uchun vositalar:
Top comments (0)