13UnitTests

Unit Test’lar haqida (1.4). Nimani test qilish kerak, nimani shartmas?

Nimani test qilish kerak, nimani shartmas?

Juda yaxshi savol. Juda keng savol. Vaziyatga qarang. Agarda siz shu bo‘lim ishlamasligi mumkin deb gumon qilsangiz – test yozing. Ammo bu unchalik keng bo‘lmagan javob. Lekin siz bularni hammasini aniq javob olish uchun o‘qiyapsizku? Quyidagi joylarni testlar bilan qamrash haqida o‘ylab ko‘ring:

  • Shartli operatorlar.

  • Ssikllar

  • Jarayonlar

  • Polimorfizm.

Boshqalar tarafidan yozilgan kodni test qilmang (sizda unga ishonmaslikga asos bo‘lmasa). Ba’zi xolatlarda tashqi kodni kamchiliklari yozilayotgan kodga qo‘shimcha mantiq qo‘shishga undaydi. Tashqi kodni ishlashini test qilish kerakmi? Ba’zida tashqi kodni xatoligini test yordamida xujjatlashtirib qo‘yish lozim shunda tashqi kodni keyingi versiyasida agar u xatolik to‘g‘irlangan bo‘lsa test ham ishlatishdan to‘xtaydi.

Testlar qancha bo‘lishi kerak?

Agarda sharoit xatoliklar kelib chiqishi orasidagi o‘rtacha vaqt 10 yildan 100 yilgacha oshirilishi kerakligini talab etsa, demak, tizimni juda ham kam holatlarda kelib chiqishi mumkin bo‘lgan xatoliklarga tekshirishga e’tibor qaratish lozim (albbata, agarda, boshqacha yo‘l bilan bunday vaziyatlar hech qachon kelib chiqishi mumkin emasligini istoblash mumkin bo‘lmasa).

TDD doirasida test qilishga qarash pragmatik bo‘ladi. TDD da barcha testlar maqsadga erishishidagi vosita hisoblanadi. Maqsad esa, to‘g‘riligiga biz kerakli miqdorda ishonuvchi kod. Agarda qandaydir kod hech qanday testsiz ham to‘g‘ri ishlab turganligi shundoq ham aniq bo‘lib tursa, test yozish kerak emas.

Qanday qilib yaxshi test yozish mumkin?

Gerard Meszaros yaxshi testlarni tuzishga bag‘ishlangan kitob yozgan: xUnit Test Patterns. Bu kitob test-infected odamlar orasida “klassika”ga aylanib bo‘ldi. Gerard kitobni miqdori uchun kechirim so‘radi (833 bet), ammo bu kitob avtomatlashtirilgan testlar yozishga odatlangan dasturchilar uchun haqiqiy xazina.

Agarda sizda kitobni boshidan oxirigacha o‘qishga 60 soat (har bir betiga 4 minut) vaqt topilmasa, hechqisi yo‘q. Google TechTalk da Gerard’ning 1 soatli chiqishi bor. Juda yaxshi chiqish.

Yana bir foydali resurs: kitobga bag‘ishlangan sayt . Unda xilma xil savollarga javob topish mumkin, testlovchi kodni tashkillashtirishdan boshlab ma’lumotlar bazasini test qilishgacha.

Testlarni yozish me’morchilik savollariga ham bog‘liqmi?

Xa, so‘zsiz. Modulni aloxida ajratilgan muhitda test qilish ehtiyoji natijasida kodni birikmasi kamayadi (loose coupling). Ya’ni, tizim yanada shivich va o‘zgarishlarga moslashuvchan bo‘ladi.

Yaxshi testlanuvchan me’moriy uslub ajoyib xususiyatga ega bo‘ladi – u maksimal osonlikga intiladi. Kerak bo‘lmagan har qanday narsa – olib tashlanadi (Lean Software Development ning yana bir tartibi – Eliminate Waste).

Bu bo‘limda klassika foydali bo‘ladi.

  • Martin Fowler – Patterns of Enterprise Application Architecture

  • Martin Fowler – Refactoring

  • Steve McConnell – Code Complete

  • GoF – Design Patterns

  • Martin Faulerning sayti

Krzysztor Cwalina .NET Framework dasturchilari guruhini program manager’i va Framework Design Guidelines kitobini muallifi, framework’larni tuzishdagi juda yaxshi yondashuv haqida aytib o‘tgan. Bu usul quyidagicha: framework’da biron bir ishni bajaruvchi kodni yozishdan avval, uni ishlatuvchi kodni yozing. Shunday tarzda, framework’ning qulayligini tezda baholab olishingiz mumkin. Bu TDD da qabul qilingan yondashuv bilan yaxshi mos tushadi: oldin qandaydir ishni bajaruvchi kodga testni yozamiz (hatto test qilinadigan kodni o‘zi tugatilmagan bo‘lsa ham), shundan keyin esa dasturni kompilyatsiya qilishga majburlaymiz.

Eski kod bilan ishlayotgan bo‘lsak nima qilish kerak?

Xa, bizga eski kod bilan ishlash nasib etgani bilan omadimiz keldi. Test me’morchiligi haqida nima ham aytish mumkin. Michael Feathers’ning Working Effectively with Legacy Code kitobida quyidagi savollarga javob topish mumkin:

Eski kodning qaysi joylarini test bilan qamrash lozim?

Oldin testmi yoki refaktoringmi?

Bu klassni testlar bilan qamray olish uchun, men kodni refaktoring qilishim kerak, ammo u testlar bilan qamralmagan va bunda men u bu narsani buzib qo‘yishim mumkin – tovuq va tuxum muammosini qanday yechish mumkin?

Ushbu maqola rsdn.ru saytida keltirilgan maqola asosida yozildi.

Farxod Dadajonov

(417 marta o'qilgan, bugun 1 marta o'qildi)

O'xshash maqolalar: