Bileşen Testi — Sınıf Adı Değişti, Test Neden Kırıldı?
Önce şunu oku: Erişilebilirlik Temelleri — Gözü Kapalı Para Gönderebilir misin?
30 saniyede özet
Bileşenin içine bakan testler, davranış aynıyken kırılır ve gerçek hatayı kaçırır. Testing Library ile öğeleri rol ve etiketle bulup kullanıcı gibi yazan, tıklayan testler düzenlemede yeşil, hatada kırmızı kalır.
Bir araç muayenesinde iki muayeneci var. Biri boyanın rengine ve cıvataların markasına bakıyor; öbürü arabayı sürüp fren yapıyor. Yeniden boyanan araba ilkinden kalıyor, freni tutmayan araba ondan geçiyor.
-
Bayt: Havale formunda düğmenin CSS sınıfını yeniden adlandırdım. Kırk test kırmızı!
-
Sen: Hepsini düzelttim. Bir hafta sonra tutar boşken Gönder çalışmaya başladı.
-
Bayt: Ve hiçbir test kırılmadı. Testler düğmenin sınıfına bakıyormuş, ne yaptığına değil.
-
Bayt: Arabanın rengine değil, sürüşüne bakmamız gerekiyor.
Test neye bakıyor?
Bir test bileşenin iç ayrıntısına bakabilir: hangi CSS sınıfı var, hangi state değişkeni değişti. Bu testler, davranış aynıyken kod yeniden düzenlenince kırılır.
Daha kötüsü, gerçek bir hatayı kaçırabilir. Tutar boşken Gönder çalışsa bile “setAmount çağrıldı” testi yeşil kalır; çünkü davranışa hiç bakmamıştır.
Kafam karıştı, daha basit anlat
İçe bakan test, düzenlemede kırılır, hatada yeşil kalır.
İyi bir bileşen testi neyi kontrol etmeli?
Bir düğmenin CSS sınıfı yeniden adlandırıldı, davranışı aynı. İyi bir test ne yapmalı?
Kullanıcı gibi test et
Test, düğmeyi rolü ve üstündeki yazıyla buluyor: Gönder. Biri düğmenin CSS sınıfını yeniden adlandırdı, davranış aynı. Test ne der? Cevabı göster
Yeşil kalır. Rol de yazı da değişmedi. Test, kullanıcının gördüğüne bakıyor; kullanıcı için hiçbir şey değişmedi.
Adım adım oku
- Araba yeniden boyandı: muayeneden kaldı.
- Fren tutmuyor: boya aynı, geçti.
- Öbür muayeneci arabayı sürüyor.
- Rengine değil, sürüşüne bak.
Testing LibraryBileşeni kullanıcı gibi test etmeye yarayan kütüphane: öğeleri rol, etiket ve metinle bulur, yazar, tıklar ve ekranda ne olduğuna bakar.Sözlükte gör → öğeleri kullanıcının bulduğu gibi bulur: rolü, etiketi, metni. Sonra kullanıcı gibi yazar, tıklar ve ekranda ne olduğuna bakar.
Bu yüzden bir düğmeyi getByRole('button', { name: 'Gönder' }) ile bulmak, onun accessible nameBir kontrolün ekran okuyucuda okunan adı. label for, düğmenin yazısı, aria-label ya da aria-labelledby'dan gelir.Sözlükte gör → da sınar. Test bir alanı bulamıyorsa, ekran okuyucu da çoğu zaman bulamaz.
Kafam karıştı, daha basit anlat
Öğeyi rolü ve yazısıyla bul, kullanıcı gibi yaz ve tıkla, ekranda ne olduğuna bak.
Testing Library'de bir düğmeyi bulmanın önerilen yolu hangisi?
Tıklanan bir div, gerçek bir button'a çevrildi. getByRole kullanan test ne olur?
Kendin gör
Havale formu üç kez değişiyor
Tohum 26051- 1. CSS sınıfı .btn-send, .send-button oldu · davranış aynı
- 2. Tıklanan div, gerçek bir <button> oldu · davranış aynı
- 3. Hata: tutar boşken Gönder çalışıyor · gerçek hata
⚠ boşuna kırmızı: 0 · ✕ kaçan hata: 0
Şu an ne oldu?
İç ayrıntı: sınıf adı, setAmount çağrıldı mı
Form değişiyor; testler her değişiklikten sonra çalışıyor.
Görevler0/3
Gerçek hata yeşil geçsinaçık
İpucu
İç ayrıntıya bak.
Her değişiklikte kırmızı yansınaçık
İpucu
Bütün HTML.
Düzenlemede yeşil, hatada kırmızıaçık
İpucu
Kullanıcı gibi.
Olay günlüğü (0)
Henüz olay yok. Oynat veya adımla.
- Varsayılanla oynat. İç ayrıntıya bakan testler iki düzenlemede boşuna kırıldı, gerçek hatada yeşil kaldı.
- “Snapshot” seç. Her değişiklikte kırmızı: hata da yakalandı, ama iki boşuna alarmın arasında kayboldu.
- “Kullanıcı gibi” seç. İki düzenlemede yeşil, gerçek hatada kırmızı.
Snapshot testinin en büyük sorunu nedir?
Test 'setAmount çağrıldı mı' diye bakıyor. Tutar boşken Gönder çalışıyor. Test ne der?
Tuzaklar
Her şeyi snapshot’a bağlamak. Bir snapshot testiBileşenin bütün çıktısını kayıtlı bir kopyayla karşılaştıran test. Her farkta kırmızı yanar; neyin önemli olduğunu söylemez.Sözlükte gör → her farkta kırmızı yanar ve hangisinin önemli olduğunu söylemez. Ekip bir süre sonra onu körü körüne günceller; bir gün gerçek hatayla birlikte.
Bekleyen yazıyı hemen aramak. “Havale gönderildi” bir saniye sonra geliyorsa, getByText onu bulamaz. await findByText(...) yazı görünene kadar bekler; sabit bir süre beklemek ise testi yavaş ve kararsız yapar.
Bulunamayan alanı test kimliğiyle geçiştirmek. Önce alana gerçek bir etiket ekle. Test kimliği son çaredir.
Kafam karıştı, daha basit anlat
Snapshot’ı az kullan, yazıyı findBy ile bekle, eksik etiketi test kimliğiyle örtme.
Kaydet'e basınca bir saniye sonra "Havale gönderildi" yazıyor. Testte bu nasıl beklenir?
Derinleş · Mobil bankacılık: havale formunu kullanıcı gibi test etmek 3 dosya · ~73 satır · ilk okumada atlayabilirsin
Kendini sına
Bir CSS sınıfının adını değiştirmek iyi bir testi kırmalıdır.
getByRole bir alanı bulamıyor; alanın görünür bir etiketi yok. En doğru çözüm hangisi?
Aklında kalacak üç şey
- 1 İç ayrıntıya bakan test, davranış aynıyken kırılır ve gerçek hatayı kaçırabilir. Bir süre sonra kimse kırmızıya inanmaz.
- 2 Testing Library ile öğeler rol, etiket ve metinle bulunur; test kullanıcı gibi yazar, tıklar ve ekranda ne olduğuna bakar.
- 3 getByRole bir alanı bulamıyorsa, ekran okuyucu da çoğu zaman bulamaz. Test burada bir erişilebilirlik eksiğini haber verir.
4 kart sonraki derste seni bekliyor