Düzəlişi necə təsdiqləmək olar

Xal hesablanmasını düzəltdik. Cavabda terminal çıxışı, tablo ekran görüntüsü və qısa "hazırdır" mesajı var; fayllar çoxdur, sual isə sadədir: bunlardan hansı tapşırığın tələbini təsdiqləyir?

Sübut düzəlişin yanında təsadüfən peyda olan istənilən fayl deyil. Bu, konkret yoxlamanın nəticəsidir: nəyin yoxlandığını, kodun hansı vəziyyətində yoxlandığını və nəticədə nə alındığını göstərir. Müxtəlif materiallar müxtəlif suallara cavab verir, heç biri isə hamısına birdən cavab vermir.

Tələbi yoxlanıla bilən iddiaya necə çevirməyi, əmrin icrası barədə nə yazmağı, logun, diff-in və ekran görüntüsünün nəyi təsdiqlədiyini nəzərdən keçirək. Sonra bunları altı sahədən ibarət qısa EVIDENCE_LOG jurnalında birləşdirib, hazır materiallar dəstinin yetərli olub-olmadığını qiymətləndirək.

Meyar yoxlamanı müəyyən edir

Məqalə boyu eyni nümunəyə baxacağıq: tabloda hesabı göstərilən kiçik bonus oyunu. Başlanğıc hesabı 0-dır, üç uyğunluq 3 xal gətirməlidir, düzəlişdən əvvəl isə 30 xal verirdi. Hesablama qaydası bu oyun üçün nəzərdə tutulub; başqa layihədə qayda fərqli ola bilər, onu ora köçürməyin.

"Hesab düzəldildi" ifadəsini yoxlamaq olmur: nəyi işə salmaq və nəyə baxmaq aydın deyil. Yoxlanıla bilən iddia üç hissədən qurulur: başlanğıc vəziyyət, əməl və gözlənilən müşahidə. Məsələn: "hesab 0 olanda üç uyğunluq 3 xal əlavə edir və tabloda 3 görünür". İndi bu iddia üçün yoxlama var.

Sonra bu iddia ayrı-ayrı müşahidələrə bölünür. Hesablama ilə oyunçunun gördüyü nəticə ayrı şeylərdir və müxtəlif üsullarla təsdiqlənir. Cədvəlin üçüncü sətri liderbordda xalın yazılması haqqındadır: tapşırıqda belə tələb olmaya bilər, amma varsa, onu ayrıca müşahidə etmək lazımdır.

Burada ən faydalı hissə üçüncü sütundur. Sübut demək olar ki, həmişə istədiyimizdən azını təsdiqləyir; sərhəd görülmüş əməl bitən yerdə keçir. Nümunəmizdə hesablama testi tablonu yoxlamır, tablo görüntüsü isə dəyişdirilmiş kod sətrini göstərmir.

İki şeyi ayrı saxlayın: tələb sonda doğru olmalı olan şeydir, nəticə isə faktiki əldə etdiyinizdir. Bunlar eyni abzasda qarışanda "3 xal əlavə etməlidir" səssizcə "3 xal əlavə edir" ifadəsinə çevrilir, halbuki heç kim heç nə işə salmayıb.

Əmr və onun nəticəsi

Yoxlamanın icrasını beş məqamla təsvir edin. Bir həftə sonra onu təkrarlayacaq şəxs üçün bunların heç biri öz-özünə aydın deyil:

• əmrin işə salındığı qovluq;
• əmrin özü, olduğu kimi;
• kodun vəziyyəti: düzəlişdən əvvəl, sonra və commit edilməmiş hansı dəyişikliklərlə;
• nəticə: çıxış kodu və yekun sayğaclar;
• hansı yoxlamalar həqiqətən icra olunub, hansılar yox.

"npm test işə salınmalıdır" ilə "npm test işə salındı, budur çıxış" ifadələrini ayırmaq vacibdir. Birincisi gələcək üçün təlimat və plandır. İkincisi faktdır. Niyyəti nəticə kimi göstərmək asandır, xüsusən də cavabda nəyin yoxlanmalı olduğu səliqə ilə sadalananda.

npm test "ümumiyyətlə bütün testləri" işə salmır. O, seçilmiş npm layihəsinin package.json faylındakı scripts bölməsinin test sahəsində yazılanı icra edir. Hansı layihənin seçildiyini təxmin etməmək üçün əmri onun kök qovluğundan işə salın və jurnalda həmin qovluğu qeyd edin. Qonşu layihədə eyni adlı skript başqa aləti, başqa addımları işlədə və ya heç nə etməyə bilər.

Əmr çıxış kodu ilə tamamlanır: 0 adətən "alət icranı uğurlu sayır" deməkdir. bash-da onu əmrin ardınca dərhal echo $? göstərir; PowerShell-də npm kimi xarici proqram üçün bu, $LASTEXITCODE-dur. Amma sıfır lazım olan testin icra olunduğunu göstərmir: testi buraxmış, adına görə filtrləmiş və ya ümumiyyətlə yazmamış ola bilərlər. Buna görə çıxış kodunun yanında sayğaclar və maraqlandığınız testin adı da olmalıdır.

Logdan nəyi saxlamaq lazımdır

İcra çıxışı uzun ola bilər, onu bütövlükdə jurnala köçürmürlər. Qısa hissədə dörd məlumat olsun: uğursuz testin adı, gözlənilən və faktiki dəyər, uğursuzluğun səbəbi və yekun sayğaclar. Qalanı link verəcəyiniz faylda saxlanılır. Aşağıda işə salınmış yoxlamanın qeydi deyil, qısaldılmış tədris nümunəsi var.

✖ three matches give 3 points (2.4108ms)
  AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
  30 !== 3
      at TestContext.<anonymous> (src/bonus-game/score.test.js:8:10)
ℹ tests 1
ℹ pass 0
ℹ fail 1
ℹ skipped 0

Bu, fraqmentdir; tam çıxış, məsələn, logs/test-fail.txt faylında saxlanılır. Buradan əsas məqam aydındır: məhz üç uyğunluq testi uğursuz olub, 3 gözlənilib, 30 alınıb, buraxılmış yoxlama yoxdur.

Xam çıxış jurnala olduğu kimi daxil edilir. Öz sözlərinizlə izah ("test səhv əmsala görə uğursuz oldu") daha aydın görünə bilər, amma bu artıq nəticə çıxarmaqdır, müşahidə deyil; onu jurnala əsasən yoxlamaq olmur. İkisini yanaşı saxlayın: əvvəl alətin sətirləri, sonra sizin izahınız.

Stack trace-dəki ünvan yoxlamanın işə düşdüyü yeri, yəni test faylını göstərir. Səbəbi oyun kodunda axtarırlar; orada tapılan əmsal kodu oxumağın nəticəsidir, log sətri deyil. Jurnalda bu iki mənbəni fərqli işarələyin, yoxsa 10 rəqəminin haradan gəldiyini sonra ayırd etmək çətin olacaq.

Diff nəyi təsdiqləyir

Diff faylın iki vəziyyəti arasındakı fərqi göstərir. O, düzəlişdən sonrakı kodun heç olmasa bir dəfə işə salındığını demir, davranışın gözlədiyiniz kimi dəyişdiyini isə heç demir.

--- a/src/bonus-game/score.js
+++ b/src/bonus-game/score.js
@@ -1,5 +1,5 @@
-const POINTS_PER_MATCH = 10;
+const POINTS_PER_MATCH = 1;

 function calcScore(matches) {
   return matches * POINTS_PER_MATCH;
 }

Belə fraqmentin altında hansı vəziyyətlərin müqayisə olunduğunu göstərən bir sətirlik qeyd olmalıdır. Məsələn, "işçi qovluq düzəlişdən əvvəlki a1b2c3d commit-i ilə müqayisədə, əmr git diff HEAD"; buradakı identifikator tədris nümunəsidir, jurnalınızda öz həqiqi identifikatorunuzu yazın. Bu əmr izlənən cari faylları, commit üçün hazırlanmış dəyişikliklər də daxil olmaqla, HEAD ilə müqayisə edir. HEAD olmadan adi git diff yalnız hazırlanmış vəziyyətlə fərqi göstərir və git add-dan sonra boş ola bilər. Qeyd yoxdursa, diff "nəsə nəsə ilə" kimi görünür və müqayisəni təkrarlamaq mümkün olmur.

Testdə gözlənilən dəyərin dəyişmədən 3 qaldığını ayrıca yoxlayın. Kodla birlikdə gözlənilən rəqəm də dəyişibsə, bu artıq başqa məsələdir: yoxlama davranışa uyğunlaşdırılıb, davranış isə tələbə yox.

Burada asanlıqla səhv salına bilən kiçik texniki məqam var. Düzəliş commit edilməyənədək onu işçi qovluğun son commit-lə müqayisəsində görmək olur. Commit-dən sonra eyni müqayisə boş nəticə verəcək; bu, tapşırıqda heç nə dəyişməyib demək deyil. Dəyişiklik tarixçəyə düşüb və commit-i əvvəlki vəziyyətlə müqayisə etmək lazımdır. Boş diff öz-özlüyündə heç nə sübut etmir; hansı iki vəziyyəti müqayisə etdiyiniz vacibdir.

Ekran görüntüsündə nə görünür

Vəziyyət və əməl

Tabloda 3 rəqəmi olan görüntü yalnız bunu təsdiqləyir: çəkiliş anında tabloda 3 var idi. Bu, "üç uyğunluq 3 xal əlavə etdi" demək deyil. Bu iki iddianın arasında görüntüdə olmayan hər şey dayanır: hesaba hansı rəqəmlə başladınız və ümumiyyətlə nə etdiniz.

Görüntünün sübut olması üçün yanında ssenarini qeyd edin:

1. nə açıldı: səhifənin ünvanı və ya işə salma üsulu, həmçinin versiyanın düzəlişli olub-olmaması;
2. başlanğıc vəziyyət: başlanğıc hesabı 0-dır, köhnə məlumat yüklənməyib;
3. əməl: üç uyğunluq toplanıb;
4. müşahidə: tabloda 3 var, görüntü əməldən dərhal sonra çəkilib.

Bu qeyd olmadan istənilən görüntünü onlarla üsulla əldə etmək olar. Dünəndən açıq qalmış, köhnə versiyanı göstərən brauzer tabı, başqa işə salma, sıfırdan fərqli olan hesab - bütün bunlar inandırıcı görünən, amma heç nə ifadə etməyən şəkil yarada bilər.

Bu məqalədə tablo görüntüsü qəsdən verilməyib. Yoxlama üçün ekran görüntüsünü lazımi versiyada ssenarini təkrarladıqdan sonra əl ilə və ya avtomatlaşdırma vasitəsilə çəkin. İllüstrasiya üçün rəsm edilmiş və ya montaj edilmiş tablo, eynilə görünsə belə, sübut sayılmır. Öz görüntünüzü hazırlayanda tablonu bütöv çəkin, ssenari qeydində səhifənin ünvanını göstərin və görüntünü həmin qeydin yanında saxlayın. Yoxsa bir həftə sonra bunun hansı işə salma olduğunu xatırlamayacaqsınız.

Model nə oxuya bilər

Şəkli sessiyaya göndərib oxumasını istəyə bilərsiniz. Burada ifadə tərzi hər şeyi həll edir: əvvəlcədən müəyyən edilmiş nəticəni təsdiqləməyi yox, görünən rəqəmi söyləməyi və şübhələri sadalamağı istəyin ("başlanğıc vəziyyət görünürmü?", "hansı versiya olduğu aydındırmı?"). "Xətanın düzəldiyini təsdiqlə" xahişinə heç nəyi yoxlamayan nəzakətli razılıq almaq asandır.

Şəkil göndərmək imkanı işlədiyiniz modeldən və mühitdən asılıdır. Claude Code-da saxlanmış şəklin yolunu göstərə və onu oxumasını xahiş edə bilərsiniz. Şəkil yüklənməyibsə, əvvəlcə yolu və faylın əlçatanlığını yoxlayın; təkcə modeli dəyişmək problemin həllinə zəmanət vermir.

Eyni ssenari: əvvəl və sonra

Faydalı cütlük belə görünür: eyni yoxlama nasaz reallaşdırmada uğursuz olur, düzəldilmişdə isə keçir. Uğursuzluq yoxlamanın bu xətanı ümumiyyətlə aşkar etdiyini, uğurlu nəticə isə düzəlişdən sonra yoxlanmış ssenaridə xətanın qalmadığını göstərir.

Bir şərtlə işləyir: eyni ilkin məlumatlar və eyni gözləntilər müqayisə edilir. Başlanğıc hesabı da, uyğunluqların sayı da, gözlənilən 3 dəyəri də eyni qalır. Düzəlişdən sonra eyni testin uğurlu nəticəsi budur:

✔ three matches give 3 points (1.3983ms)
ℹ tests 1
ℹ pass 1
ℹ fail 0
ℹ skipped 0

İcralar arasında reallaşdırma dəyişir, test, giriş məlumatları, gözlənti və işə salma şərtləri isə eyni qalır. Tələbi dəyişmək və ya testdə gözlənilən dəyəri düzəltmək lazım gəlibsə, bu yoxlama ilə yeni icra cütü əldə edin: sözlə izah onu hər iki vəziyyətdə işə salmağı əvəz etmir. Belə halda izahsız "qırmızı idi, yaşıl oldu" demək yanlış təsəvvür yaradır.

before.txt və after.txt adlı iki fayl da öz-özlüyündə heç nəyə zəmanət vermir. Faylın adı sübut deyil. İçinə baxmaq lazımdır: əmr eynidirmi, test eynidirmi, gözlənti eynidirmi? Nasaz vəziyyətə nəzarətli qayıdış (git stash ilə olan üsul) öz qaydaları olan ayrıca yoxlamadır. Burada bilmək kifayətdir ki, düzəlişdən əvvəlki uğursuz nəticə yaddaşdan yox, həqiqi icradan götürülür.

Qısa EVIDENCE_LOG

EVIDENCE_LOG bu məqalədə aşağıdakı ardıcıllıqla altı sahədən ibarət adi mətn jurnalını bildirir: ƏLAMƏT, LOG-SÜBUTU, NASAZ VƏZİYYƏTDƏ UĞURSUZLUQ, DÜZƏLİŞ, HƏQİQİ UĞURLU NƏTİCƏ, EKRAN GÖRÜNTÜSÜ. Bu ardıcıllıq əlaməti, düzəlişi və nəticəni tutuşdurmağı asanlaşdırır. Amma sahələrin ardıcıllığı qeydlərin etibarlılığına zəmanət vermir.

Yuxarıda topladıqlarımızın hamısı bu sahələrə yerləşir. Əmr və qovluq uğursuz icra sahəsinə, müqayisə edilən vəziyyətlər düzəliş sahəsinə, tam fayllara keçidlər isə onların mənbəyinə yazılır. Yanında daha bir sənəd dəsti yaratmağa ehtiyac yoxdur.

Aşağıda doldurmağın tədris nümunəsi var: hər sahəyə nə yazılacağını göstərir, yerinə yetirilmiş yoxlamalar barədə hesabat vermir. Öz jurnalınızda mətni faktiki nəticələrlə əvəz edin.

ƏLAMƏT: bonus oyununda başlanğıc hesabı 0 olanda üç uyğunluq
3 əvəzinə 30 xal verir. Hər dəfə təkrarlanır: oyunu açın,
üç uyğunluq toplayın, tabloya baxın.

LOG-SÜBUTU: icra çıxışında "30 !== 3", testdə
"three matches give 3 points"; tam çıxış logs/test-fail.txt faylındadır.
Ayrıca, kodu oxuyarkən müəyyən edilib: src/bonus-game/score.js faylında
POINTS_PER_MATCH əmsalı 10-dur. Bu, kodun oxunmasından alınan nəticədir,
test çıxışında 10 rəqəmi yoxdur.

NASAZ VƏZİYYƏTDƏ UĞURSUZLUQ: HEAD a1b2c3d (tədris identifikatoru),
işçi qovluq təmizdir; commit-də nasaz hesablama və test var.
Qovluq - /project/bonus-game, əmr - npm test.
package.json daxilində scripts.test = node --test. "three matches give 3 points" uğursuz olur,
səbəb "30 !== 3", tests 1, pass 0, fail 1, skipped 0, çıxış kodu 1.
Çıxış fraqmenti yuxarıdadır, tam çıxış - logs/test-fail.txt.

DÜZƏLİŞ: POINTS_PER_MATCH src/bonus-game/score.js faylında
10-dan 1-ə dəyişdirilib; başqa dəyişiklik yoxdur. HEAD yenə a1b2c3d-dir.
Diff: git diff HEAD, işçi qovluq bu commit-lə müqayisədə;
diffs/score-fix.diff faylında saxlanılıb.
Testdə gözlənilən dəyər əvvəlki kimi 3 qalıb.

HƏQİQİ UĞURLU NƏTİCƏ: eyni əmr, npm test, eyni qovluqdan,
təsvir edilən düzəlişdən sonrakı kodda icra olunub. Eyni test keçir:
tests 1, pass 1, fail 0, skipped 0, çıxış kodu 0.
Tam çıxış - logs/test-pass.txt.
Beş uyğunluqlu ssenari işə salınmayıb.

EKRAN GÖRÜNTÜSÜ: screenshots/bonus-score-3.png. Düzəlişdən sonra
oyun eyni işçi qovluqdan http://localhost:3000 ünvanında yenidən açılıb.
Başlanğıc hesabı 0, üç uyğunluq toplanıb,
tabloda 3 görünür. Nəticənin liderbordda saxlanması yoxlanılmayıb.

Nümunədəki yollar sadəcə nümunədir. Tam logları, diff-ləri və şəkilləri layihədə oxşar faylların saxlandığı yerə qoyun; bunun üçün ayrıca məcburi qovluq strukturu yaratmaq lazım deyil.

5-ci və 6-cı sahələrin son sətirlərinə diqqət edin. Buraxılmış yoxlama qısa şəkildə birbaşa qeyd olunur: "işə salınmayıb", "yoxlanılmayıb". Bu, tənbəlliyi etiraf etmək deyil, nəticənin sərhədidir. Belə sətirlərsiz jurnal daha dolğun görünür, amma əslində heç kimin etmədiyi işlər barədə susur.

Özünüzü yoxlayın

Tapşırıqda iki meyar var: başlanğıc hesabı sıfır olanda üç uyğunluq 3 xal verir və həmin üç uyğunluqdan sonra interfeysdə 3 görünür. Əlinizdə altı material var:

1. agentin "hazırdır, xəta düzəldildi" mesajı;
2. npm test işə salmaq barədə təlimat;
3. eyni testin faktiki icraları: düzəlişdən əvvəl uğursuz, sonra uğurlu;
4. əmsalın dəyişdirildiyini göstərən diff;
5. işə salma təsviri olmayan, 3 rəqəmli tək görüntü;
6. görüntü ilə əlaqələndirilmiş təkrar ssenari qeydi.

İki meyar üçün bunlardan hansı yetərlidir, hansı hissə yoxlanılmamış qalır? Davamını oxumazdan əvvəl cavabı düşünün.

İzahı: birinci meyarı 3-cü bənd qarşılayır - eyni testin həqiqi icra cütü. 4-cü bənddəki diff kodda nəyin dəyişdiyini izah edir, amma icranı əvəz etmir; dəyişiklik və icra ayrı şeylərdir. İkinci meyarı 6-cı bənd qarşılayır: başlanğıc vəziyyətin və əməlin göründüyü ssenari qeydi ilə birlikdə görüntü. 1-ci və 2-ci bənd heç nəyi təsdiqləmir: hazır olma mesajında yoxlanıla bilən sübut yoxdur, təlimat isə gələcək əməli təsvir edir. 5-ci bənd 3 rəqəmini göstərir və burada dayanır; onun əsasında xalın necə hesablandığını müəyyən etmək olmur. Üstəlik, masada altı materialın hamısı olsa belə, nəticənin liderbordda saxlanması yoxlanılmamış qalır: saxlanmış dəyərin geri oxunduğu ssenari yoxdur.

Belə jurnalı sessiyada da tərtib etmək olar. Hazır prompt:

Altı sahə üzrə EVIDENCE_LOG tərtib et. Hər nəticə üçün faktiki
yoxlamanı, kodun vəziyyətini və nəticə mənbəyini göstər.
İşə salınmayanları ayrıca qeyd et. Ekran görüntüsündə yalnız
görünənləri adlandır və daxili hesablamanın düzgünlüyü barədə nəticə çıxarma.

Claude Code ilə sübutları necə toplamaq olar

İş ardıcıllığı belədir:

1. agent hər meyarı konkret yoxlama ilə əlaqələndirir: nəyi işə salmaq, kodun hansı vəziyyətində və hansı nəticəni gözləmək;
2. bu mühitdə əlçatan olan yoxlamaları icra edir və əmri xam çıxışla birlikdə göstərir;
3. müşahidələri əlavə edir: çıxış fraqmentləri, tam fayllara keçidlər, təkrar edilmiş ssenarinin təsviri;
4. sərhədi açıq göstərir: nə işə salınmayıb və mövcud materiallara əsasən nəyi iddia etmək olmaz.

Sübutların özünü yoxlamaq sizə qalır: əlavə edilmiş faylları açıb içindəkilərə baxın, ssenarini meyarda təsvir edilənlə tutuşdurun və yoxlaması görünməyən bənd barədə bir çətin sual verin. Adətən bu, toplanmış sübutları səliqəli tərtib edilmiş nəqldən ayırmaq üçün kifayət edir.

Texniki arayış: git diff, git stash, Node.js test runner, npm test, Claude Code-da şəkillər.