Test nədir və nə üçün lazımdır

Claude Code kodu dəyişib və belə yazıb: "Testlər keçdi". Bu qısa cümlənin arxasında yoxlamalar olan fayllar, işə salma əmri və konkret nəticələr dayanır. Əvvəl testin hansı növləri olduğunu və nəyi əl ilə yoxlamaq mümkün olduğunu nəzərdən keçirək, sonra avtomatik testə və nəticəsinin mənasına baxaq.

Bunun üçün xal hesablanmasına dair kiçik bir nümunə kifayətdir. Test kitabxanalarını əvvəlcədən bilmək lazım deyil: əvvəl ssenarini əl ilə yoxlayacağıq, sonra avtomatik testlər üçün gözləntiləri müəyyənləşdirib onların nəticə hesabatını nəzərdən keçirəcəyik.

Testin hansı növləri var

Test proqramın necə davrandığını, tələblərə uyğun olub-olmadığını və problemlərin harada yarandığını anlamağa kömək edir. Məsələn, xallar düzgün hesablanırmı, boş sahə ilə müraciət göndərmək mümkündürmü, xəta mesajı aydındırmı? Bunun üçün yoxlama şərtləri seçilir, addımlar yerinə yetirilir və nəticə araşdırılır.

Testi müxtəlif əlamətlərə görə bölmək olar. Əvvəlcə addımları kimin yerinə yetirib nəticəni yoxladığına baxaq:

• manual test - yoxlamanı insan özü aparır və nəticəni qiymətləndirir;
• avtomatlaşdırılmış test - yoxlamaların bir hissəsi proqrama həvalə olunur: proqram verilmiş addımları və müqayisələri yerinə yetirir. Belə yoxlamalara adətən avtomatik testlər, yaxud avtotestlər deyilir.

Bu, testin necə aparıldığına görə bölgüdür. Başqa bir sual da var: dəqiq nə yoxlanılır? Funksional yoxlamalar davranışla bağlıdır: məsələn, nəzərdə tutulan xallar hesablanıbmı. Qeyri-funksional yoxlamalar isə tətbiqin iş xüsusiyyətlərinə aiddir: məsələn, nə qədər tez cavab verir və ya istifadəsi nə dərəcədə rahatdır. Bu əlamətlər bir-birindən asılı deyil: eyni funksiyanı həm əl ilə, həm də avtomatik yoxlamaq olar.

Avtomatlaşdırma insanın iştirakını aradan qaldırmır. Faydalı ssenariləri seçmək, gözləntiləri müəyyənləşdirmək və aşkarlanan fərqləri anlamaq yenə lazımdır. Sadəcə işin təkrarlanan hissəsini proqram yerinə yetirir.

Manual test nədir

Manual test zamanı addımları özünüz yerinə yetirir və nəticənin gözləntiyə uyğun olub-olmadığına baxırsınız. Bunun üçün test kodu yazmaq vacib deyil. Aydın şərtlər və cavabını tapmaq istədiyiniz sual kifayətdir.

Tutaq ki, tədris portalında hər uyğunluğa 10 xal verilir, deməli, üç uyğunluğa 30 xal düşür. Xalların hesablanmasını əl ilə belə yoxlamaq olar:

1. portalın lazım olan versiyasını açın və balansı sıfır olan, hələ mükafat almamış istifadəçi hazırlayın;
2. üç uyğunluğu olan müraciət hazırlayıb bir dəfə göndərin;
3. göndərişdən sonra balansa baxın: gözlənilən nəticə 30 xaldır;
4. faktiki nəticəni qeyd edin. Başqa rəqəm alınıbsa, addımları və lazım gələrsə skrinşotu saxlayın.

Burada başlanğıc balansı vacibdir. Balansda əvvəlcədən 20 xal varsa, hesablamadan sonra 30 yox, 50 xal gözləyirsiniz. İlkin şərtlər olmadan düzgün nəticəni səhv, yaxud səhvi düzgün nəticə hesab etmək asandır.

Yoxlamanın nəticəsini qısa yazmaq rahatdır: "Göndərməzdən əvvəl balans 0, üç uyğunluq, bir göndəriş, gözlənilən 30, alınan 3". Belə qeyddən başqa biri və ya Claude Code nəyi təkrarlamalı olduğunu anlayacaq. "Xallar qəribə işləyir" cümləsi isə bunu izah etmir.

Manual test araşdırma xarakterli də ola bilər: tətbiqi öyrənir, proses ərzində yeni sınaqlar fikirləşirsiniz. Məsələn, göndərişdən sonra düymənin hələ də aktiv olduğunu görüb ikinci dəfə basmağı yoxlamaq qərarına gəlirsiniz. Burada hər addım üçün əvvəlcədən müəyyən edilmiş marşrut yoxdur, amma məqsəd qalır: davranışı anlamaq və tapılan problemləri qeyd etmək. Sadəcə ora-bura klikləmək deyil.

Bu zaman alətlərdən istifadə etmək tam normaldır. Brauzer konsolunu aça, serverin cavabına baxa, skrinşot çəkə və ya yoxlamaların siyahısını tuta bilərsiniz. "Manual" sözü yoxlamanı insanın idarə etdiyini və nəticəni onun qiymətləndirdiyini bildirir, alətsiz işlədiyini yox.

Yeni davranışı araşdırmaq və ya interfeysin aydın olub-olmadığını qiymətləndirmək lazım gələndə manual yoxlama əlverişlidir. Avtomatik yoxlama isə artıq təsvir edilmiş addımları və müqayisələri dəfələrlə təkrarlamaq üçün faydalıdır. Bu, "interfeys yalnız əl ilə, hesablamalar yalnız kodla" kimi sərt bölgü deyil: brauzerdəki addımları da avtomatlaşdırmaq olar, hesablamanı isə əl ilə yoxlamaq mümkündür.

Avtotestləri işə salan düyməni basmaq hələ manual test deyil: işə saldıqdan sonra yoxlamaları proqram özü yerinə yetirir. Claude Code sizə addımların siyahısını hazırlayıbsa və portalda onları özünüz keçərək nəticəni qiymətləndirmisinizsə, yoxlama manual olaraq qalır. Agent sadəcə hazırlamağa kömək edib.

Avtomatik test nədir

Təsəvvür edin ki, kalkulyatoru yoxlayırsınız. 2 + 2 daxil edir, nəticəni görməzdən əvvəl 4 gözləyir və ekrandakı rəqəmi bu gözlənti ilə müqayisə edirsiniz. 5 görürsünüzsə, deməli, bu nümunənin nəticəsi yanlışdır. Kalkulyator nə göstərirsə göstərsin, düzgün cavabı bilirsiniz.

Avtomatik test oxşar işi proqram vasitəsilə görür. O, başlanğıc şərtləri müəyyənləşdirən, əməliyyatı yerinə yetirən və nəticəni yoxlayan kiçik proqramdır. Müqayisəni insan əvəzinə kod aparır. Bundan sonra belə avtomatik testi qısaca test adlandıracağıq.

Mükafat portalına qayıdaq: bir uyğunluq 10 xal gətirir, üç uyğunluğa isə 30 xal düşür. Yoxlamanı sözlə belə yazmaq olar:

1. uyğunluqların sayını hazırlamaq: 3;
2. mükafatın hesablanmasını yerinə yetirmək;
3. mükafatın 30-a bərabər olduğunu yoxlamaq.

Elə bu, bir test olacaq. Burada əvvəlcədən məlum nümunə və gözlənilən cavab var. "Hər uyğunluğa 10 xal" qaydası bizim tədris portalımıza aiddir; başqa tətbiqdə qayda fərqli ola bilər.

Test istifadəçiyə neçə xal düşdüyünü özü fikirləşmir. Kimsə tələblərdəki qaydanı götürüb gözləntini yazmalıdır. Bunu proqramçı və ya sizin tapşırığınızla Claude Code edə bilər, amma gözləntinin mənasını yenə də tapşırıqla tutuşdurmaq lazımdır.

Yoxlamanı niyə təkrarlamaq lazımdır

Xal hesablanmasını bir dəfə əl ilə yoxlamaq rahatdır. Problem sonra yaranır: yeni mükafat növü əlavə etdiniz, müraciətin emalını dəyişdiniz və ya agentdən funksiyanı sadələşdirməyi istədiniz. Hər belə dəyişiklikdən sonra eyni sual ortaya çıxır: üç uyğunluq yenə 30 xal verirmi?

Hər dəfə müraciəti yenidən hazırlayıb addımları yerinə yetirə və nəticəyə baxa bilərsiniz. Ya da bu yoxlamanı koda yazıb təkrar işə sala bilərsiniz. Eyni hazırlıq şərtlərində test verilmiş addımları və müqayisəni yenidən yerinə yetirəcək. Hara klikləmək və nəyi düzgün saymaq lazım olduğunu təzədən izah etməyə ehtiyac qalmayacaq.

Layihə böyüdükcə belə qaydalar da artır. Sıfır uyğunluqlu müraciət xal əlavə etməməlidir; təkrar müraciət iki dəfə hesablanmamalıdır; mükafatların siyahısı müəyyən ardıcıllıqla olmalıdır. Yoxlamaları birlikdə işə salıb dəyişiklikdən sonra hansı gözləntinin pozulduğunu görmək olar.

Avtomatlaşdırmanın faydası bundadır: təsvir edilmiş davranışı yenidən yoxlamaq daha az əl əməyi tələb edir. Testləri yazmaq da vaxt aparır, tələblər dəyişəndə onları yenidən nəzərdən keçirmək lazım gəlir. Amma daim qayıtdığınız qaydalar üçün bu iş təkrar işə salınmalarla özünü doğruldur.

Testlər harada saxlanır

Testlər layihənin adi fayllarında saxlanır. Kiçik JavaScript layihəsində yoxlamanı çağırdığı kodun yanında yerləşdirmək rahatdır:

reward-example/
├── package.json
└── src/
    ├── reward-flow.js
    └── reward-flow.test.js

reward-flow.js faylında mükafat hesablanır. reward-flow.test.js faylında isə bu hesablamanı çağırıb cavabı yoxlayan kod yerləşir. package.json layihənin parametrlərini və əmrlərini, o cümlədən test əmrini təsvir edir.

Adın .test.js hissəsi yoxlama faylını tanımağa kömək edir. Bu, test alətlərinin dəstəklədiyi razılaşmadır, JavaScript dilinin ayrıca qaydası deyil. Başqa layihələrdə fərqli adlara və ya ayrıca tests/ qovluğuna rast gəlinir. Bir faylda bir neçə test ola bilər; hər mənbə faylının yanında ayrıca test faylı saxlamaq vacib deyil.

Claude Code tanımadığınız layihədə işləyirsə, əvvəlcə mövcud xal hesablanması testini tapıb yolunu göstərməsini xahiş edin. Beləliklə, hələ bütün qovluqlarda rahat istiqamətlənməsəniz də, yoxlamanı lazım olan davranışla əlaqələndirə bilərsiniz.

Niyyəti yoxlamaya necə çevirmək olar

"Xal hesablamasını düzəlt və testlərlə yoxla" xahişi agentin qarşısında eyni anda iki sual qoyur: nəyi düzgün hesablama saymaq lazımdır və nəticəni nə ilə təsdiqləmək olar? Əvvəlcə almaq istədiyiniz davranışı təsvir edin. Məsələn: "Hər uyğunluğa 10 xal düşür. Üç uyğunluq olduqda mükafat 30 xal olmalıdır".

Belə niyyəti bir sətir kod yazmadan yoxlamaya çevirmək olar. Bunun üçün üç məqamı təsvir edin:

Bunu bir cümlə kimi oxumaq olar: "Üç uyğunluq varsa, mükafat hesablanarkən 30 xal alınmalıdır". Testin mənasını müzakirə etmək üçün burada kifayət qədər məlumat var. Bu layihədə yoxlamanı hansı kodla yazmağı isə agent həll edəcək.

Dəqiq nəyi təsdiqləmək istədiyinizi seçmək vacibdir. "30 xallıq mükafat hesablandı" və "istifadəçinin balansı 30 oldu" fərqli gözləntilərdir. İkinci hal üçün yuxarıdakı manual yoxlamadakı kimi başlanğıc balansı və xalların hesaba köçürülməsi addımı da lazımdır. Ona görə "xalları yoxla" əvəzinə dəqiq müşahidəni göstərin.

Sonra yaxın vəziyyətləri də düşünün. Bizim qaydamız üçün kiçik cədvəllə başlamaq kifayətdir:

Birdən-birə onlarla vəziyyət uydurmaq lazım deyil. Problemli ssenaridən və dəyişiklikdən təsirlənə biləcək bir neçə yaxın vəziyyətdən başlayın. Məsələn, təkrar müraciət zamanı nə baş verməli olduğu aydın deyilsə, əvvəlcə qaydanı dəqiqləşdirin. Agent variant təklif edə bilər, amma bu hələ razılaşdırılmış gözlənti deyil.

Yoxlamanı Claude Code-a necə tapşırmaq olar

Gözlənilən davranışı ifadə etdikdən sonra işi onun ətrafında qurmaq olar. Əvvəl agent layihədə hansı yoxlamaların olduğunu öyrənir, sonra onları sizin ssenarilərinizlə tutuşdurur. Lazım olan yoxlama artıq mövcud ola bilər: belədirsə, onu işə salıb nəticəni oxumaq vacibdir. Yoxdursa, agent test əlavə etməlidir.

İlk tapşırıq belə görünə bilər:

Mükafat hesablamasını düzəltmək lazımdır.
Qayda: hər uyğunluğa 10 xal verilir.
Yoxlanacaq hallar: 3 uyğunluq 30 xal verir,
0 - 0, 5 - 50 xal verir.

Dəyişiklikdən əvvəl bu hallar üçün mövcud yoxlamaları tap.
Artıq nəyin yoxlandığını, nəyin çatmadığını qısa yaz
və hansı testləri əlavə etməyi və ya dəyişməyi təklif etdiyini bildir.
Tələblərdə qeyri-müəyyənlik varsa, göstər.
Hələlik faylları dəyişmə.

Cavabı gələcək nəticənin təsviri kimi oxuyun. Bütün hallardakı rəqəmlər sizin qaydanızdan götürülüb? Məhz mükafatın miqdarı yoxlanılır, yoxsa başqa bir şey? Mövcud davranışa uyğunlaşdırmaq üçün qaydanın özünü dəyişməyi təklif etmir ki? Bu addımda tapşırığı dəqiqləşdirirsiniz, testin kodunu oxumaq lazım deyil.

Ssenariləri dəqiqləşdirdikdən sonra işi görməyi tapşırın:

Hesablamanı müzakirə etdiyimiz qaydaya uyğun düzəlt.
Razılaşdırılmış hallar üçün çatışmayan yoxlamaları əlavə et,
layihədə qəbul edilmiş alətlərdən istifadə et.
Uğurlu nəticə almaq naminə mövcud gözləntiləri dəyişmə.
Gözləntinin səhv olduğunu düşünürsənsə, əvvəlcə səbəbini izah et.

Layihənin təlimatlarına uyğun olaraq lazım olan testləri işə sal.
Əmri, iş qovluğunu və faktiki çıxışı göstər.
Üç halın hər biri üçün hansı testin yoxladığını
və necə başa çatdığını yaz. Buraxılan və işə salınmayan
yoxlamaları ayrıca sadala.

İşə salma əmrini agent layihənin sənədlərində və parametrlərində tapır. JavaScript layihəsində bu, çox vaxt npm test olur: npm package.json faylının scripts.test sahəsindəki əmri yerinə yetirir. Bu adın arxasında müxtəlif yoxlamalar ola bilər. Sizin işiniz lazım olan ssenarilərin də işə salındığına əmin olmaqdır.

Testi yazmaq və işə salmaq işin fərqli mərhələləridir. "Üç yoxlama əlavə etdim" mesajı yalnız fayllardakı dəyişikliklərdən xəbər verir. Nəticəni qiymətləndirmək üçün testləri həqiqətən işə salmaq lazımdır. Məsələn, asılılıq çatışmadığı üçün bu mümkün deyilsə, agent maneəni və yerinə yetirilməmiş yoxlamaları bildirməlidir.

Cavabda "bizim ssenari → konkret test → nəticə" əlaqəsini axtarın. Müzakirə etdiyimiz üç haldan yalnız biri işə salınıbsa, hələlik təkcə o təsdiqlənib. Yekun sətir yaşıl olsa belə.

Nəticəni necə oxumaq olar

Aşağıda Node.js 20.18.0 və npm 10.8.2 ilə bir tədris testinin həqiqi işə salınması göstərilib. O, yuxarıda təklif olunan bütün ssenariləri yox, yalnız üç uyğunluq üçün mükafat hesablamasını yoxlayır. Oxumağı asanlaşdırmaq üçün vaxt sətirləri və hesabatın xidməti hissələri çıxarılıb:

> reward-example@1.0.0 test
> node --test --test-reporter=tap

# Subtest: three matches give 30 points
ok 1 - three matches give 30 points

# tests 1
# suites 0
# pass 1
# fail 0
# cancelled 0
# skipped 0
# todo 0

İlk iki sətir paketi və yerinə yetirilən əmri göstərir. Ardınca testin adı gəlir. ok 1 sətri 1 nömrəli testin keçdiyini bildirir; uğursuz testin sətri not ok ilə başlayır. pass 1 və fail 0 sətirləri bir testin keçdiyini, heç birinin uğursuz olmadığını deyir. Terminal mətni rəngləməsə belə, buna "yaşıl" nəticə deyirlər.

Xətalı variantda üç uyğunluğa görə qaydada nəzərdə tutulan 30 əvəzinə 3 xal hesablanır. Eyni test belə bir hissə çıxarır; fayl yolu, çağırış steki, vaxt və bəzi xidməti sətirlər buraxılıb:

not ok 1 - three matches give 30 points
  error: |-
    Expected values to be strictly equal:

    3 !== 30

  code: 'ERR_ASSERTION'
  name: 'AssertionError'
  expected: 30
  actual: 3
  operator: 'strictEqual'

# tests 1
# pass 0
# fail 1
# cancelled 0
# skipped 0
# todo 0

Əvvəlcə testin adını tapın, sonra expected və actual dəyərlərini müqayisə edin. Birincisi "gözlənilən", ikincisi isə "alınan" deməkdir. Burada 30 gözlənilirdi, 3 alındı. fail 1 sətri yekunlaşdırır: bir test uğursuz oldu.

Belə uğursuzluq alınan nəticənin yazılmış gözləntiyə uyğun olmadığını bildirir. İndi səbəbi tapmaq lazımdır: hesablamada xəta, yanlış ilkin məlumatlar, yoxsa testin özündəki səhv gözlənti. Hesabat uğurlu olsun deyə yoxlamadakı rəqəmi dəyişmək olmaz: əvvəlcə tapşırığın qaydasını tutuşdurun.

Başqa cür uğursuzluq da olur: məsələn, test funksiya faylını qoşa bilməyib. Bu halda xalları müqayisə etməyə heç çatmayıb və hesabatda lazım olan testin adı belə görünməyə bilər: bütün fayl uğursuz kimi qeyd olunacaq. Buna görə fail 1 sətri "hesablama yanlışdır" nəticəsi üçün yetərli deyil. Yekundan əvvəlki mesaja baxın.

Buraxılmış test

Testin daha bir vacib vəziyyəti var. Yoxlama buraxılmış kimi işarələnə bilər; məsələn, Node.js-də bunun üçün test.skip istifadə olunur. Belə test yerinə yetirilmir. Hesabatda adının görünməsi ssenarinin yoxlandığı demək deyil.

Nümunəmizin ayrıca işə salınmasında buraxılmış test belə bir sətir və yekun nəticələr verdi:

ok 1 - three matches give 30 points # SKIP

# tests 1
# pass 0
# fail 0
# cancelled 0
# skipped 1
# todo 0

Qeyri-adi bir məqama fikir verin: sətir ok ilə başlayır, amma # SKIP ilə bitir. Bu format buraxılmış testi belə qeyd edir. Yalnız ilk sözə baxmaq olmaz; yekundakı pass 0 heç bir testin keçmədiyini təsdiqləyir.

Eyni ssenarinin üç işə salınmasını müqayisə edək:

Böyük hesabatlarda başqa sətirlər də var. Bizim işə salınmalarda cancelled və todo sıfıra bərabərdir. Sıfırdan fərqli rəqəmlər görsəniz, hansı testlərin ləğv edildiyini və ya tamamlanmamış kimi qeyd olunduğunu araşdırın; onları uğurla yoxlanmış saymayın. suites sətri test qruplarına aiddir: nümunəmizdə qrup yoxdur.

Bir xırda məqam da var. Hesabatda sıfır test göstərilirsə, uğursuzluğun olmaması xal hesablamasını təsdiqləmir. Lazım olan yoxlama işə salınanların sırasına düşməmiş ola bilər. Ssenarinin adı və yerinə yetirilən yoxlamaların sayı terminalın rəngi barədə ümumi təəssüratdan daha vacibdir.

Yaşıl nəticə nə deməkdir

Göstərilən hesabatdakı test dar bir suala cavab verdi: "Üç uyğunluq üçün mükafat düzgün hesablanıbmı?" O, sıfır uyğunluğu, təkrar müraciəti və ya səhifədəki rəqəmi yoxlamadı. Tapşırıqda bu halların adını çəkməyimiz onları yoxlanmış etmir.

Sıfır uyğunluğu yoxlamaq üçün ayrıca 0 gözləntisi olan daha bir ssenari lazımdır. Təkrar müraciəti yoxlamaq üçün məhz təkrar addımı və onun gözlənilən nəticəsini təsvir etmək gərəkdir. Test bu qaydaları yanındakı koda baxıb təxmin etməyəcək. Yalnız testdə yazılan yoxlanılır.

Testin olmaması onun buraxılmasından fərqlənir. Buraxılmış test hesabatda skipped kimi görünür. Yoxlaması heç yazılmamış ssenari barədə isə hesabat adətən heç nə demir. Yoxlanmamış davranışda xəta olsa da, mövcud testlərin hamısı keçə bilər.

Nəhayət, müqayisənin uğurlu olması gözləntinin özünü düzgün etmir. Qaydamıza görə səhvən 30 əvəzinə 3 yazılsa və hesablama da 3 versə, müqayisə keçəcək. Buna görə yoxlamanı müzakirə edərkən iki suala cavab vermək faydalıdır: test hansı davranışı yoxlayır və gözlənilən nəticə haradan götürülüb?

"Testlər keçdi" cümləsi sərhədlərini başa düşəndə faydalıdır. O, konkret işə salınmada konkret yoxlamaların uğurlu olduğunu bildirir. "Tətbiqdə artıq xəta yoxdur" vədi vermir.