Test Əsaslı İnkişaf nədir, yanaşmalar və üstünlüklər

Test Dəstəkli İnkişaf (TDD) kodun nə edəcəyini müəyyən etmək və təsdiqləmək üçün test işlərinin işlənib hazırlandığı proqram təminatının inkişafı yanaşmasıdır.

Proqram təminatı buraxılmazdan əvvəl hər bir funksiya üçün faktiki olaraq test nümunələri yaradılır və sınaqdan keçirilir və əgər test uğursuz olarsa, testdən keçmək və kodu sadə və səhvsiz etmək üçün yeni kod yazılır (və ya yenidən yazılır və ya yamaqlanır).

Test Əsaslı İnkişaf (TDD) proqramdakı hər kiçik xüsusiyyət üçün testlərin dizaynı və inkişafı ilə başlayır. TDD çərçivəsi tərtibatçılara yalnız avtomatlaşdırılmış test uğursuz olduqda yeni kod yazmağı tapşırır. Bu yanaşma kodun təkrarlanmasının qarşısını alır. Tam TDD modulu test əsaslı inkişafdır.

Test Əsaslı İnkişaf (TDD) Agile proqram təminatının inkişaf etdirilməsi metodologiyasının bir hissəsi olan Ekstremal Proqramlaşdırma (XP) kimi tanınan daha böyük proqram dizayn paradiqmasının bir hissəsi kimi yaranmışdır.

TDD-nin sadə konsepsiyası yeni kod yazmadan əvvəl (inkişafdan əvvəl) uğursuz testləri yazmaq və düzəltməkdir. Bu, testlərdən keçmək üçün hər dəfə az miqdarda kod yazdığımız üçün kodun təkrarlanmasının qarşısını alır. (Testlər, onları təmin etmək üçün sınaqdan keçirməli olduğumuz tələb şərtlərindən başqa bir şey deyil).

Test əsaslı inkişaf, tətbiqin faktiki inkişafından əvvəl avtomatlaşdırılmış testlərin hazırlanması və icrası prosesidir. Beləliklə, TDD bəzən Test İlk İnkişaf adlanır.

TDD yanaşmasının mərhələləri

Hər hansı yeni kod yazılmazdan əvvəl proqramçı əvvəlcə uğursuz vahid testi yaratmalıdır. Sonra proqramçı - və ya cütlük və ya mob - bu tələbi ödəmək üçün kifayət qədər kod yaradır. Testdən keçdikdən sonra proqramçı davranışı dəyişmədən təkmilləşdirmələr edərək layihəni refaktor edə bilər.

TDD vahid səviyyəli proqramçı qarşılıqlı əlaqəsinə diqqət yetirsə də, müştərilər tərəfindən başa düşülən testlərə diqqət yetirən qəbul testinə əsaslanan inkişaf (ATDD) və ya davranışa əsaslanan inkişaf (BDD) kimi digər məşhur üsullar da mövcuddur.

Bu üsullar kodlaşdırmadan əvvəl mühəndis işçiləri və müştəri arasında əməkdaşlıq testləri kimi real dünya nümunələri yaratmağı və kodun həyata keçirildiyini nümayiş etdirmək üçün kodlaşdırmadan sonra testləri həyata keçirməyi əhatə edir. Testlərin əvvəlcədən bilinməsi ilk dəfə keyfiyyəti artırır. ATDD və BDD kod yaradılmazdan əvvəl proqram təminatını və onun nəticələrini təsəvvür etmək və müzakirə etmək üçün tərtibatçılardan, sınaqçılardan və biznes tərəfindən birgə işləməyi tələb edir.

TDD-nin üstünlükləri

Testə əsaslanan inkişaf köhnə üsullarla mümkün olduğundan daha az vaxt ərzində yüksək keyfiyyətli tətbiqlər yarada bilər. TDD-nin müvəffəqiyyətlə tətbiqi tərtibatçılardan və testçilərdən tətbiqin və onun funksionallığının real dünyada necə istifadə olunacağını dəqiq təxmin etməyi tələb edir.

TDD yan təsir kimi reqressiya test paketi qurur ki, bu da insanın əllə sınaqdan keçirilməsini minimuma endirir, problemləri daha əvvəl tapır və daha sürətli həllər verir. TDD-nin metodik təbiəti klassik mərhələli kod dövrləri > test > düzəltmə > təkrar sınaqdan daha yüksək ilk dəfə əhatə və keyfiyyət təmin edir. Test dizayn dövrünün əvvəlində aparıldığı üçün, sonradan sazlamaya sərf olunan vaxt və pul minimuma endirilir.

Gözlənilən faydalar:

• ilkin inkişaf səylərinin orta dərəcədə artması bahasına qüsur dərəcələrində əhəmiyyətli azalmalar
• qaimə məsrəfləri layihələrin son mərhələlərində səylərin azalması ilə kompensasiya olunur
• TDD kodda daha yaxşı dizayn keyfiyyətlərinə və daha çox "daxili" və ya texniki keyfiyyətin daha yüksək dərəcəsinə gətirib çıxarır, məsələn, birləşmə və birləşmə ölçülərini təkmilləşdirməklə

TDD-nin çatışmazlıqları

TDD, xüsusilə vahid səviyyəsində müvəffəqiyyətli olmaq üçün əhəmiyyətli bacarıq tələb edir. Bir çox köhnə sistemlər sadəcə olaraq vahid sınağı nəzərə alınmaqla qurulmur, bu da test üçün komponentləri təcrid etməyi qeyri-mümkün edir.

Həmçinin, bir çox proqramçıda təmiz kod təcrid etmək və yaratmaq bacarığı yoxdur. Bütün komanda üzvləri vahid testləri yaratmalı və saxlamalıdırlar, əks halda onlar tez köhnələcəklər. Və TDD-yə baxan bir təşkilat daha sonra daha sürətli getmək üçün vaxt ayırmalı, indi bir az yavaşlamalı olacaq.

Nəhayət, hər hansı bir metodda olduğu kimi, TDD-nin yekun nəticələri yalnız istifadə edilən testlər, onların nə dərəcədə dəqiq yerinə yetirildiyi və son məhsulun istifadəçilərinin qarşılaşdıqları şərtləri nə dərəcədə təqlid etdiyi qədər yaxşıdır.

Ümumi səhvlər:

• tez-tez testlər keçirməyi unutmaq
• bir anda çoxlu test yazın
• çox böyük və ya kobud testlər yazın
• iddiaları buraxmaq kimi həddindən artıq əhəmiyyətsiz testlər yazmaq
• mənasız kod üçün testlər yazın
• qismən övladlığa götürmə: işçi qrupunda yalnız bir neçə tərtibatçı TDD-dən istifadə edir
• yoxsul test paketinə texniki qulluq, ən çox uzun müddət işləmə müddəti olan bir test paketinə gətirib çıxarır
• test paketi tərk edildi (yəni nadir hallarda və ya heç vaxt işləmir) - bəzən zəif texniki xidmət, bəzən komanda dövriyyəsi səbəbindən

TDD fəlsəfəsi

TDD proqramçıya proqram yazarkən körpə addımlarını atmağa imkan verir. Test funksionallığı sınaqdan keçirməzdən əvvəl yazılır və tətbiqin sınaqdan keçirilməsinə uyğun olmasını təmin edir. Test edilmiş kodda baş verən səhvləri tutmaq üçün az miqdarda kod üzərində sınaq aparılır. Sonra funksionallıq həyata keçirilir. Buna "qırmızı yaşıl refaktor" deyilir, burada qırmızı uğursuzluq deməkdir və yaşıl keçid göstərir. Sonra bu addımlar təkrarlanır. Proqramçının ilk məqsədi diqqəti qarşıya qoyulan vəzifəyə cəmləmək və onun öhdəsindən gəlməkdir.

Testə əsaslanan inkişaf dövrünün müxtəlif mərhələləri bunlardır:

• Test əlavə edin: TDD-də hər bir yeni xüsusiyyət hər hansı bir funksiya həyata keçirilməzdən əvvəl yerinə qoyulduğu üçün uğursuz olmalı olan bir testlə başlayır. Xüsusiyyəti tətbiq etməzdən əvvəl test yazmaq üçün ilkin şərt, tərtibatçı tərəfindən tələbin aydın şəkildə başa düşülməsidir. Bu, istifadəçi hekayələri və istifadə halları vasitəsilə əldə edilir. Beləliklə, tərtibatçı proqram kodunu yazmazdan əvvəl tələbi başa düşür.
• Bütün testləri yerinə yetirin və yeni kodun uğursuz olub-olmadığını yoxlayın: bu, test kəmərinin düzgün işləməsini və yeni testin heç bir yeni kod olmadan uğursuz olmasını təmin edir. Bu addım həm də testi yoxlayır və yeni testin həmişə keçəcəyi ehtimalını aradan qaldırır.
• Kod yaz: Sonrakı addım testi təmizləyən kodu yazmaqdır. Yeni kod mükəmməl deyil, lakin sonradan tələblərə uyğun olaraq dəyişdirilir. O, sadəcə sınaq üçün nəzərdə tutulmuşdur və başqa heç bir funksiyanı ehtiva etmir.
• Avtomatlaşdırılmış Testləri Çalışın: Əgər istehsal edilən hər bir test işi testdən asanlıqla keçərsə, bu, kodun bütün tələb olunan spesifikasiyalara cavab verdiyini bildirir. Sonra dövrün son mərhələsinə başlamaq olar.
• Refaktorinq kodu: Bu, təkrarlamanın aradan qaldırılmasına bənzəyir. Refaktorinq heç bir mövcud funksionallığı pozmur və istehsal və sınaq kodu arasında təkrarlanmanı aradan qaldırmağa kömək edir. İndi kod tələb olunduğu kimi təmizlənir.
• Təkrar et: Dövr əvvəlki hallarda olduğu kimi yeni bir testlə təkrarlanır. Əsas tələb odur ki, addım ölçüsü kiçikdir, hər sınaq qaçışı arasında təxminən 1-10 dəyişiklik var. Yeni kod yeni bir testdə uğursuz olarsa, proqramçı daha çox sazlama işləri aparmalıdır. Davamlı inteqrasiya geri dönən nəzarət nöqtələrini təmin edir.

Ercole Palmeri