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 testlarni run 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 umuman buglarsiz 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 yoki drag-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 elementini loading yoki disabled holatini redux yoki useState da saqlayotganimiz foydalanuvchi uchun muhimmas (bilishi kerak ham emas), unga buttondagi visual o'zgarishni ko'rish muhim). Lekin bu holatda odatda ko'plab mocklar ishlatamiz, componentning 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'ni dependency 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), tasodifiy breaking 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 proyektlarda contributorlarning 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:

• https://about.codecov.io
• https://docs.cypress.io/guides/tooling/code-coverage