Qancha Code Coverage yetarli?
Tags: javascript, testing, webdev, programming
Published: 2023-03-30 13:07:15

### Bismillah
 
Assalom alaykum!

> Taxminiy o'qish vaqti: ~3 daqiqa

[**Code coverage**](https://www.codegrip.tech/productivity/everything-you-need-to-know-about-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 `bug`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 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 `mock`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 :no_entry_sign:. Ushbu [maqolada](https://kentcdodds.com/blog/testing-implementation-details) **Kent C. Dodds** buni juda ajoyib qilib tushuntirgan.

> [**_mocking_**](https://stackoverflow.com/questions/2665812/what-is-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**_](https://en.wikipedia.org/wiki/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_](https://stackoverflow.com/questions/980601/what-is-an-anti-pattern):
- _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` :boom: 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 `contributor`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**:
- https://about.codecov.io
- https://docs.cypress.io/guides/tooling/code-coverage