TDD və vahid testi nədir [tərcümə]

Bu məqalə The Complete Software Career Guide kitabından bir fəslin uyğunlaşdırılmasıdır. Onun müəllifi Con Sönmez bunu yazır və bəzi fəsilləri öz saytında yerləşdirir.

Başlayanlar üçün qısa lüğət

Vahid sınağı və ya vahid testi proqramlaşdırmada proqramın mənbə kodunun fərdi modullarının düzgünlüyünü yoxlamağa imkan verən bir prosesdir. İdeya, hər bir qeyri-trivial funksiya və ya metod üçün testlər yazmaqdır. Reqressiya testi mənbə kodunun artıq sınaqdan keçirilmiş sahələrində səhvləri aşkar etməyə yönəlmiş bütün növ proqram testlərinin ümumi adıdır. Belə səhvlər - proqrama dəyişikliklər etdikdən sonra işləməyə davam etməli olan bir şey işləməyi dayandırdıqda - reqressiya səhvləri adlanır. Qırmızı nəticə, uğursuzluq - testin uğursuzluğu. Gözlənilən nəticə ilə faktiki nəticə arasındakı fərq. Yaşıl nəticə, keçid - müsbət test nəticəsi. Faktiki nəticə əldə ediləndən heç də fərqlənmir. *** Sevgidən nifrətə və yenidən geriyə gedən Test Əsaslı İnkişaf (TDD) və vahid testi ilə çox qarışıq münasibətim var. Mən həvəskar bir fan idim və eyni zamanda bunun və digər "ən yaxşı təcrübələrin" istifadəsi ilə bağlı şübhəli bir skeptik idim. Münasibətimin səbəbi proqram təminatının hazırlanması proseslərində ciddi problemin ortaya çıxması ilə bağlıdır: tərtibatçılar, bəzən də menecerlər müəyyən alət və metodologiyalardan yalnız “ən yaxşı təcrübələrə” aid olduqları üçün istifadə edirlər. Onların istifadəsinin əsl səbəbi bəlli deyil. Bir gün mən müəyyən bir layihə üzərində işləməyə başladım və bu prosesdə çoxlu sayda vahid testlərinin əhatə etdiyi kodu dəyişdirəcəyimiz barədə məlumat aldım. Zarafat deyil, onların təxminən 3000-i var idi.Bu, adətən yaxşı əlamətdir, tərtibatçıların qabaqcıl metodologiyalardan istifadə etdiyinə işarədir. Bu yanaşma ilə kod ən çox strukturlaşdırılmışdır və yaxşı düşünülmüş arxitekturaya əsaslanır. Bir sözlə, testlərin olması məni sevindirdi, yalnız ona görə ki, bu mənim proqramçıların mentoru kimi işimi asanlaşdırmaq deməkdir. Artıq vahid testlərimiz olduğundan, mənim etməli olduğum tək şey onları dəstəkləmək və öz kodumuzu yazmağa başlamaq üçün inkişaf komandasına qoşulmaq idi. IDE (inteqrasiya edilmiş inkişaf mühiti) açdım və layihəni yüklədim. Bu, böyük bir layihə idi! Mən "vahid testləri" etiketli bir qovluq tapdım. "Əla" deyə düşündüm. - Gəlin onu işə salaq və görək nə olacaq. Cəmi bir neçə dəqiqə çəkdi və məni təəccübləndirdi ki, bütün testlər keçdi, hər şey yaşıl idi ( "yaşıl" testin müsbət nəticəsidir. Kodun gözlənildiyi kimi işlədiyini bildirir. Qırmızı "uğursuzluğu" və ya uğursuzluğu bildirir, sonra kodun düzgün işləmədiyi bir hal var - tərcüməçinin qeydi ). Hamısı imtahandan keçdilər. Bu an içimdəki skeptik oyandı. Necə oldu ki, üç min vahid test etdi və hamısını birdən aldılar və müsbət nəticə verdilər? Uzun təcrübəmdə kodda bir mənfi vahid testi olmayan bir layihə üzərində işləməyə başladığım vaxtı xatırlaya bilmədim. Nə etməli? Əl ilə yoxlayın! ChY ən aşkar yox, təsadüfi bir test seçdi, amma nəyi yoxladığı dərhal aydın oldu. Ancaq bunun üzərində işləyərkən mən absurd bir şey gördüm: testdə gözlənilən nəticə ilə heç bir müqayisə yox idi (təsdiq edir)! Yəni əslində heç nə yoxlanılmayıb ! Testdə müəyyən addımlar var idi, həyata keçirilirdi, amma testin sonunda faktiki və gözlənilən nəticələri müqayisə etməli olduğu yerdə yoxlama yox idi. “Sınaq” heç nəyi sınamadı. Başqa bir test açdım. Daha da yaxşısı: nəticə ilə müqayisə operatoru şərh edilmişdir. Möhtəşəm! Bu, sınaqdan keçmək üçün əla bir yoldur, sadəcə uğursuzluğa səbəb olan kodu şərh edin. Başqa bir test yoxladım, sonra başqa... Heç biri heç nə yoxlamadı. Üç min test və hamısı tamamilə yararsızdır. Vahid testlərinin yazılması ilə vahid testini başa düşmək və testə əsaslanan inkişaf (TDD) arasında böyük fərq var.

Vahid sınağı nədir?

Vahid testinin əsas ideyası kodun ən kiçik “vahidini” sınaqdan keçirən testlər yazmaqdır. Vahid testləri adətən proqramın mənbə kodu ilə eyni proqramlaşdırma dilində yazılır. Onlar birbaşa bu kodu sınamaq üçün yaradılmışdır. Yəni vahid testləri digər kodun düzgünlüyünü yoxlayan koddur. Mən “test” sözünü kontekstdə kifayət qədər sərbəst şəkildə istifadə edirəm, çünki vahid testlər müəyyən mənada test deyil. Onlar heç nə yaşamırlar. Demək istədiyim odur ki, siz vahid testini işlədəndə adətən bəzi kodun işləmədiyini görmürsünüz. Bunu testi yazarkən kəşf edirsiniz, çünki test yaşıllaşana qədər kodu dəyişəcəksiniz. Bəli, kod sonradan dəyişə bilər və sonra testiniz uğursuz ola bilər. Beləliklə, bu mənada vahid test reqressiya testidir. Vahid testi, izləyəcəyiniz bir neçə addımın olduğu və proqram təminatının düzgün işlədiyini və ya işləmədiyini gördüyünüz adi test kimi deyil. Bir vahid testinin yazılması prosesi zamanı kodun etməli olduğu şeyi edib-etmədiyini kəşf edirsiniz və test keçənə qədər kodu dəyişəcəksiniz. Niyə vahid testi yazın və keçib-keçmədiyini yoxlayın? Əgər siz bu şəkildə düşünürsünüzsə, onda vahid testləri çox aşağı səviyyədə müəyyən kod modulları üçün bir növ mütləq tələblərə çevrilir. Vahid testini mütləq spesifikasiya kimi düşünə bilərsiniz . Vahid testi müəyyən edir ki, bu şərtlər altında bu xüsusi giriş dəsti ilə bu kod vahidindən əldə etməli olduğunuz bir çıxış var. Həqiqi vahid testi, əksər proqramlaşdırma dillərində - ən azı obyekt yönümlü olanlarda - bir sinif olan ən kiçik əlaqəli kod vahidini müəyyən edir.

Bəzən vahid testi nə adlanır?

Vahid sınağı çox vaxt inteqrasiya testi ilə qarışdırılır. Bəzi "vahid testləri" birdən çox sinfi yoxlayır və ya böyük kod vahidlərini sınaqdan keçirir. Bir çox tərtibatçı, əslində aşağı səviyyəli ağ qutu testləri yazarkən vahid testləri yazdıqlarını iddia edirlər. Bu adamlarla mübahisə etməyin. Sadəcə bilin ki, onlar həqiqətən inteqrasiya testləri yazır və həqiqi vahid testləri digər hissələrdən təcrid olunmuş şəkildə ən kiçik kod vahidini yoxlayır. Tez-tez vahid testi adlanan başqa bir şey, gözlənilən dəyərlə yoxlanılmadan vahid testləridir. Başqa sözlə, əslində heç bir şeyi sınamayan vahid testləri. Birləşdirilmiş və ya olmayan hər hansı bir test bir növ yoxlamanı ehtiva etməlidir - biz bunu faktiki nəticənin gözlənilən nəticə ilə yoxlanılması adlandırırıq. Testin keçib-keçmədiyini müəyyən edən bu uzlaşmadır. Həmişə keçən bir sınaq faydasızdır. Həmişə uğursuz olan bir sınaq faydasızdır.

Vahid Testinin Dəyəri

Niyə mən vahid test həvəskarıyam? Başqa koddan təcrid olunmuş ən kiçik bloku yox, daha böyük kod parçası olan “vahid sınağı”nı sınaqdan keçirməyi nəzərdə tutan ümumiləşdirilmiş test adlandırmaq niyə zərərlidir? Bəzi testlərim alınan və gözlənilən nəticələri müqayisə etmirsə, problem nədir? Heç olmasa kodu icra edirlər. izah etməyə çalışacağam. Vahid testinin aparılmasının iki əsas səbəbi var. Birincisi, kod dizaynını təkmilləşdirməkdir. Yadda saxlayın ki, vahid sınağı həqiqətən test deyil? Düzgün vahid testləri yazdığınız zaman özünüzü ən kiçik kod vahidini təcrid etməyə məcbur edirsiniz. Bu cəhdlər sizi kodun strukturunda problemlər aşkarlamağa aparacaq. Test sinfini təcrid etmək və onun asılılıqlarını daxil etməmək çox çətin ola bilər və bu, kodunuzun çox sıx birləşdiyini başa düşməyə vadar edə bilər. Sınamağa çalışdığınız əsas funksionallığın bir neçə modulu əhatə etdiyini və kodunuzun kifayət qədər ardıcıl olmadığına inanmağınıza səbəb ola bilər. Bir vahid testi yazmaq üçün oturduğunuz zaman, birdən kodun nə etməli olduğu barədə heç bir fikrinizin olmadığını aşkar edə bilərsiniz (və inanın ki, bu baş verir!). Müvafiq olaraq, bunun üçün vahid test yaza bilməyiniz mümkün deyil. Və əlbəttə ki, kodun həyata keçirilməsində əsl səhv tapa bilərsiniz, çünki vahid testi sizi qutudan kənarda düşünməyə və hesab etmədiyiniz müxtəlif giriş dəstlərini sınamağa məcbur edir. Əgər siz vahid testləri yaratarkən “ən kiçik kod vahidini digərlərindən təcrid olunmuş şəkildə sınayın” qaydasına ciddi əməl etsəniz, həmin kod və modulların dizaynı ilə bağlı hər cür problemlə qarşılaşacaqsınız. Proqram təminatının inkişafının həyat dövründə vahid testi sınaq fəaliyyətindən daha çox qiymətləndirmə fəaliyyətidir. Vahid testinin ikinci əsas məqsədi proqram davranışının aşağı səviyyəli spesifikasiyası kimi çıxış edə bilən reqressiya testlərinin avtomatlaşdırılmış dəstini yaratmaqdır. Bunun mənası nədi? Xəmir yoğurduqda qırılmır. Bu baxımdan vahid testlər testlər, daha dəqiq desək, reqressiya testləridir. Bununla belə, vahid testinin məqsədi sadəcə reqressiya testlərini qurmaq deyil. Təcrübədə vahid testləri nadir hallarda reqressiyaları tutur, çünki sınadığınız kod vahidinə edilən dəyişiklik demək olar ki, həmişə vahid testinin özündə dəyişiklikləri ehtiva edir. Reqressiya testi daha yüksək səviyyədə kod “qara qutu” kimi sınaqdan keçirildikdə daha effektiv olur, çünki bu səviyyədə kodun daxili strukturu dəyişdirilə bilər, xarici davranışın isə dəyişməz qalacağı gözlənilir. Vahid sınaqları öz növbəsində daxili strukturu yoxlayır ki, həmin struktur dəyişdikdə vahid sınaqları uğursuz olmasın. Onlar yararsız hala düşür və indi dəyişdirilməli, atılmalı və ya yenidən yazılmalıdır. İndi bir çox veteran proqram tərtibatçılarından daha çox vahid testinin əsl məqsədi haqqında daha çox bilirsiniz.

Test Əsaslı İnkişaf (TDD) nədir?

Proqram təminatının hazırlanması prosesində yaxşı bir spesifikasiya qızıl kimi dəyərlidir. TDD yanaşması ondan ibarətdir ki, hər hansı kodu yazmazdan əvvəl ilk növbədə spesifikasiya kimi xidmət edəcək bir test yazırsınız, yəni kodun nə etməli olduğunu müəyyənləşdirirsiniz. Bu son dərəcə güclü proqram inkişaf konsepsiyasıdır, lakin tez-tez sui-istifadə olunur. Tipik olaraq, test əsaslı inkişaf proqram kodunun yaradılmasına rəhbərlik etmək üçün vahid testlərindən istifadə deməkdir. Amma əslində bu yanaşma istənilən səviyyədə tətbiq oluna bilər. Bununla belə, bu məqalədə tətbiqimiz üçün vahid testindən istifadə etdiyimizi güman edəcəyik. TDD yanaşması hər şeyi öz üzərinə götürür və bu kodu yoxlamaq üçün əvvəlcə kod yazıb sonra vahid testləri yazmaq əvəzinə, siz əvvəlcə vahid testi yazın, sonra isə həmin testi yaşıl etmək üçün kod yazın. Bu şəkildə, vahid testi kodun işlənməsini "sürür". Bu proses dəfələrlə təkrarlanır. Siz kodun nə etməli olduğuna dair daha çox funksionallığı müəyyən edən başqa bir test yazırsınız. Daha sonra testin uğurla başa çatmasını təmin etmək üçün kodu yazın və dəyişdirin. Yaşıl nəticə əldə etdikdən sonra kodu refaktorlamağa başlayırsınız, yəni onu daha yığcam etmək üçün onu yenidən düzəldirsiniz və ya təmizləyirsiniz. Bu proseslər zənciri tez-tez "Qırmızı-Yaşıl-Refaktorinq" adlanır, çünki əvvəlcə vahid testi uğursuz olur (qırmızı), sonra kod testə uyğunlaşmaq üçün yazılır, müvəffəqiyyətli olduğundan əmin olun (yaşıl) və nəhayət kod optimallaşdırılır ( refaktorinq).

TDD-nin məqsədi nədir?

Test əsaslı inkişaf (TDD), vahid testi kimi, səhv istifadə edilə bilər. Etdiyiniz işi "TDD" adlandırmaq və hətta bunu niyə belə etdiyinizi başa düşmədən təcrübəyə riayət etmək çox asandır. TDD-nin ən böyük dəyəri keyfiyyət spesifikasiyaları hazırlamaq üçün testlərin aparılmasıdır. TDD əslində kodlaşdırma yazılmamışdan əvvəl avtomatik yoxlanıla bilən dəqiq spesifikasiyaların yazılması təcrübəsidir. Testlər ən yaxşı spesifikasiyalardır, çünki yalan danışmırlar. İki həftəlik əzabdan sonra sizə “heç nə demək istədiyim deyildi” kodu ilə deməyəcəklər. Testlər düzgün yazıldığında ya keçər, ya da uğursuz olur. Testlər müəyyən şərtlərdə nə baş verməli olduğunu aydın şəkildə göstərir. Beləliklə, TDD-nin məqsədi onu həyata keçirməyə başlamazdan əvvəl bizə nəyi həyata keçirməli olduğumuz barədə tam bir anlayış verməkdir. Əgər siz TDD ilə başlayırsınızsa və testin nəyi sınamalı olduğunu anlaya bilmirsinizsə, daha çox sual verməlisiniz. TDD-nin digər mühüm rolu kodu qorumaq və optimallaşdırmaqdır. Kodun saxlanması bahalıdır. Mən tez-tez zarafat edirəm ki, ən yaxşı proqramçı hansısa problemi həll edən ən yığcam kodu yazandır. Və ya hətta bu problemin həllinə ehtiyac olmadığını sübut edən və bununla da kodu tamamilə silən, çünki səhvlərin sayını azaltmağın və tətbiqin saxlanması xərclərini azaltmağın düzgün yolunu tapan bu proqramçı idi. TDD-dən istifadə etməklə, siz heç bir lazımsız kod yazmadığınıza tam əmin ola bilərsiniz, çünki siz yalnız testlərdən keçmək üçün kod yazacaqsınız. YAGNI adlı proqram təminatının işlənib hazırlanması prinsipi var (sizin buna ehtiyacınız olmayacaq). TDD YAGNI-nin qarşısını alır.

Tipik Test Əsaslı İnkişaf (TDD) İş Akışı

TDD-nin mənasını sırf akademik baxımdan başa düşmək çətindir. Beləliklə, TDD sessiyasının bir nümunəsinə baxaq. Təsəvvür edin ki, masanızda oturub istifadəçiyə proqrama daxil olmaq və parolunu unutduqda onu dəyişmək imkanı verən funksiyanın yüksək səviyyəli dizaynı olacağını düşündüyünüzü tez bir zamanda cızmaq olar. Siz giriş prosesinin bütün məntiqini idarə edəcək bir sinif yaradaraq, giriş funksiyasının ilk tətbiqi ilə başlayacağınıza qərar verirsiniz. Siz sevimli redaktorunuzu açır və "Boş giriş istifadəçinin daxil olmasına mane olur" adlı vahid testi yaradırsınız. Siz əvvəlcə Login sinfinin nümunəsini yaradan vahid test kodunu yazırsınız (hələ bunu yaratmamısınız). Daha sonra siz Login sinfində boş istifadəçi adı və parolu ötürən metodu çağırmaq üçün kod yazırsınız. Nəhayət, gözlənilən nəticəyə qarşı bir çek yazırsınız, boş girişi olan istifadəçinin əslində daxil olmadığını yoxlayırsınız. Siz test keçirməyə çalışırsınız, lakin o hətta tərtib etmir, çünki Login sinifiniz yoxdur. Siz bu vəziyyəti düzəldin və daxil olmaq üçün həmin sinifdə bir metodla birlikdə Giriş sinfi və daxil olub-olmadığını yoxlamaq üçün istifadəçinin statusunu yoxlamaq üçün başqa bir üsul yaradırsınız. İndiyə qədər siz bu sinfin funksionallığını və bizə lazım olan metodu tətbiq etməmisiniz. Bu nöqtədə sınaqdan keçirsiniz. İndi o, tərtib edir, lakin dərhal uğursuz olur. İndi koda qayıdın və testdən keçmək üçün funksionallığı həyata keçirin. Bizim vəziyyətimizdə bu o deməkdir ki, nəticə əldə etməliyik: "istifadəçi daxil deyil." Testi yenidən keçirdiniz və indi keçdi. Gəlin növbəti testə keçək. İndi təsəvvür edək ki, “İstifadəçi etibarlı istifadəçi adı və parol daxil edibsə, daxil olub” adlı test yazmalısınız. Siz Login sinfini yaradan və istifadəçi adı və şifrə ilə daxil olmağa cəhd edən vahid testi yazırsınız. Bir vahid testində siz istifadəçinin daxil olub-olmaması sualına Login sinfinin bəli cavab verməsi barədə bəyanat yazırsınız. Siz bu yeni testi icra edirsiniz və əlbəttə ki, uğursuz olur, çünki Login sinifiniz həmişə istifadəçinin daxil olmadığını bildirir. Siz Login sinifinizə qayıdırsınız və istifadəçinin daxil olduğunu yoxlamaq üçün bəzi kod tətbiq edirsiniz. Bu vəziyyətdə, bu modulu necə təcrid edəcəyinizi anlamalı olacaqsınız. Hələlik bunu etmənin ən asan yolu testinizdə istifadə etdiyiniz istifadəçi adı və parolu kodlaşdırmaqdır və əgər onlar uyğun gəlirsə, onda "istifadəçi daxil olub" nəticəsini qaytarmaqdır. Siz bu dəyişikliyi edirsiniz, hər iki testi yerinə yetirirsiniz və hər ikisi keçər. Son mərhələyə keçək: siz yaradılan koda baxırsınız və onu yenidən təşkil etmək və sadələşdirmək üçün bir yol axtarırsınız. Beləliklə, TDD alqoritmi belədir:

1. Test yaratdı.
2. Bu test üçün kod yazdıq.
3. Kodu refaktor etdi.

nəticələr

Bu mərhələdə vahid test və TDD haqqında sizə demək istədiyim hər şey budur. Əslində, kod modullarını təcrid etmək cəhdi ilə bağlı bir çox çətinliklər var, çünki kod çox mürəkkəb və çaşdırıcı ola bilər. Tam təcrid olunmuş siniflər çox azdır. Əvəzində onların asılılıqları var və o asılılıqların da asılılıqları var və s. Belə vəziyyətlərin öhdəsindən gəlmək üçün TDD veteranı asılı modullarda obyektləri əvəz etməklə fərdi sinifləri təcrid etməyə kömək edən istehzalardan istifadə edir. Bu məqalə sadəcə ümumi baxışdır və vahid sınağı və TDD-yə bir qədər sadələşdirilmiş girişdir, biz dummy modullar və digər TDD üsulları haqqında ətraflı məlumat verməyəcəyik. İdeya sizə TDD və vahid testinin əsas anlayışlarını və prinsiplərini verməkdir ki, ümid edirəm ki, indi sizdə var. Orijinal - https://simpleprogrammer.com/2017/01/30/tdd-unit-testing/