Test Çerçeveleri Mühendislik Kültürünü ve Kaliteyi Nasıl Şekillendirir

Kültür ile Ne Kastediyoruz ve Neden Araçlar Önemli\n\n"Mühendislik kültürü" soyut gelebilir ama çok pratik şekillerde kendini gösterir: insanlar meşgulken varsayılan olarak ne yapıyor, baskı altında nasıl takaslar yapılıyor ve hangi davranışlar "normal" veya "riskli" sayılıyor. Günlük alışkanlıklar—kod değişmeden önce küçük bir test yazmak, kontrolleri yerel çalıştırmak, inceleme istemek, varsayımları belgelemek—zaman içinde sessizce kaliteyi tanımlar.\n\n### Kültür bir dizi varsayılandır\n\nÇoğu ekip kültürü toplantılarda tartışmaz. Kültür şu şekilde yansır:\n\n- Standartlar: "iyi"nin neye benzediği (ve yine de hangi kodun merge edildiği).\n- Karar verme: insanların güvenli yolu mu yoksa en hızlı yolu mu seçtiği.\n- Geri bildirim döngüleri: bir şeyin bozulduğunu ne kadar hızlı öğrendiğiniz.\n- Sorumluluk: sorunların düzeltme ile mi yoksa suçlama ile mi sonuçlandığı.\n\nBu desenler, ekibin günlük deneyimleriyle pekişir. Kalite kontrolleri yavaş, belirsiz veya sancılıysa insanlar onlardan kaçınmayı öğrenir. Hızlı ve bilgilendirici ise insanlar doğal olarak onlara güvenir.\n\n### Bir test çerçevesi sadece bir araç değildir\n\n"Test çerçevesi" derken yalnızca assertion API'sinden bahsetmiyoruz. Bir çerçeve genellikle şunları içerir:\n\n- Araçlar: çalıştırıcılar, assertion'lar, fixture'lar/mock'lar, raporlama, watch modu.\n- Konvansiyonlar: testlerin nasıl yapılandırıldığı, adlandırıldığı ve organize edildiği.\n- İş akışları: testlerin yerelde ve CI'de nasıl çalıştığı, hataların nasıl gösterildiği, neyin "yeterli" sayıldığı.\n\nBu paket geliştirici deneyimini şekillendirir: test yazmanın kodlamanın normal bir parçası mı yoksa ertelenen ekstra bir iş mi olduğunu belirler.\n\n### Bu makale araç savaşı değil, davranış değişikliği hakkında\n\nFarklı çerçeveler iyi sonuçlar üretebilir. Daha önemli soru şudur: bu çerçeve varsayılan olarak hangi davranışları teşvik ediyor? Sürdürülmesi kolay test yazmayı kolaylaştırıyor mu? Net başarısızlık mesajlarını ödüllendiriyor mu? CI hattınıza sorunsuz entegrasyon sağlıyor mu?\n\nBu detaylar ekibinizin nasıl çalıştığını ve pratikte kalitenin ne anlama geldiğini etkiler. Amaç, ekiplerin hızlı geri bildirim, net beklentiler ve sürümlerde güven gibi iyi alışkanlıkları pekiştirecek şekilde test çerçevelerini seçip kullanmasına yardımcı olmaktır.\n\n## Çerçeveler Günlük Alışkanlıkları Şekillendiren Varsayılanlar Oluşturur\n\nBir test çerçevesi tarafsız değildir. Onun "mutlu yolu" hangi testlerin önce yazılmasının normal hissettirdiğini (ve hangilerinin isteğe bağlı göründüğünü) sessizce belirler.\n\n### Önce ne test edilir: birimler mi uçtan uca mı\n\nBir çerçeve küçük, izole testleri zahmetsizce ayağa kaldırmayı kolaylaştırdığında (hızlı runner, minimal boilerplate, basit parametrize), ekipler genellikle birim testleriyle başlar çünkü geri bildirim anlıktır. Eğer en kolay kurulum bir tarayıcı runner'ı veya tam uygulama harness'i ise, insanlar genellikle daha yavaş ve teşhisi zor olsa bile uçtan uca kontrollerle başlar.\n\nZamanla bu varsayılan kültüre dönüşür: "Çalıştığını tıklayarak kanıtlıyoruz" veya "Mantığı doğrulayarak kanıtlıyoruz."\n\n### Davranışı yönlendiren varsayılanlar\n\nÇerçeveler aşağıdaki yollarla görüş içselleştirir:\n\n- Assertion'lar: okunabilir, spesifik assertion'lar kesin beklentileri teşvik eder; belirsiz matcher'lar "yeterince yakın" kontrollerini davet eder.\n- Fixture'lar: iyi fixture desenleri tekrar kullanım ve netlik sağlar; kullanışsız fixture'lar kopyala-yapıştır kurulumlara ve gizli bağımlılıklara yol açar.\n- Mock'lama: hafif mock'lama izolasyonu yaygın hale getirir; ağır mock API'leri aşırı mock'lamaya ve kırılgan testlere teşvik edebilir.\n\nBunlar soyut seçimler değildir—test adlandırma, modül yapılandırması ve test kodunu ne sıklıkla refactor ettiğiniz gibi günlük alışkanlıkları şekillendirir.\n\n### "Kolay" vs "acı veren" testler hangi testlerin yazılacağını belirler\n\nBir test yazmak küçük bir fonksiyon eklemek gibi geliyorsa, bu normal geliştirme sırasında yapılır. Eğer config, global'ler veya yavaş başlangıçla uğraşmak gerekiyorsa, testler "daha sonra yapılacak" iş haline gelir. Araç sürtüşmesi sonra şu kestirme yolları oluşturur:\n\n- yerelde testleri atlayıp CI'ye güvenmek\n- kırılganlığı gizlemek için sleep/retry eklemek\n- test edmesi zor bileşenlerden kaçınmak için geniş E2E testleri kullanmak\n\nBu kestirmeler birikir ve çerçevenin varsayılanları ekibin kabul edilebilir kalite tanımına dönüşür.\n\n## Geri Bildirim Hızı Ekibin Ritmini Belirler\n\nBir test çerçevesi sadece kontrolleri çalıştırmaz—insanları eğitir. Geri bildirim hızlı ve yorumlaması kolay olduğunda geliştiriciler daha sık commit yapma, küçük adımlarla refactor etme ve testleri ayrı bir iş olarak değil akışın parçası olarak görme eğiliminde olur.\n\n### Hızlı geri bildirim "küçük ve kararlı"yı varsayılan yapar\n\nBir değişiklik saniyeler içinde doğrulanabiliyorsa, şunları yapmaya daha isteklisiniz:\n\n- küçük dilimler halinde commit atmak\n- kodu isimlendirmek ve yeniden düzenlemek konusunda daha az endişe duymak\n- farklı yaklaşımları denemek ve tersine almak\n\nÇerçevenin özellikleri bu davranışı doğrudan şekillendirir. Watch modu sık döngüleri teşvik eder ("kaydet → sonucu gör"), bu da deneyi normal kılar. Hedeflenmiş test seçimi (sadece etkilenen testleri çalıştırma, test dosyası desenleri veya son başarısız testler) varsayımları kontrol etme maliyetini düşürür. Paralel çalışma beklemeyi azaltır ve değişiklikleri test etmeden biriktirme baskısını ortadan kaldırır.\n\n### Yavaş test setleri korku yaratır—ve daha büyük, riskli partilere yol açar\n\nTüm suite 20–60 dakika sürerse, ekip öngörülebilir yollarla uyum sağlar: daha az çalışma, daha az commit ve "biraz daha bitireyim sonra test ederim" yaklaşımı. Bu daha büyük PR'lere, incelenmesi zor değişikliklere ve hangi değişikliğin hataya yol açtığını bulmak için daha fazla zamana yol açar.\n\nZamanla yavaş geri bildirim refactor etmeyi de caydırır. İnsanlar doğrulama maliyeti çok yüksek olduğu için tam olarak anlamadıkları kodu değiştirmekten kaçınır.\n\n### Ritmi korumak için zaman bütçeleri belirleyin\n\nEkipler hızı bir gereklilik olarak ele alabilirler, lüks değil. Basit bir politika yardımcı olur:\n\n- Birim testleri: yerelde 2–5 dakika altında\n- PR düzeyinde suite: CI'de 10–15 dakika altında\n- Daha uzun entegrasyon çalışmaları: planlı veya daha yüksek riskli değişiklikler için kapılı\n\nBütçeleri tanımladıktan sonra paralelleştirme, sharding, seçici çalıştırma gibi ayarlarla hızı ve kültürü koruyabilirsiniz.\n\n## Hataların Açıklığı Güveni İnşa Eder—veya Aşındırır\n\nBir test başarısız olduğunda ekip hemen iki soru sorar: "Ne bozuldu?" ve "Bu sinyale güvenebilir miyim?" Test çerçeveniz bu soruların saniyeler içinde mi yoksa bir sonsuz kaydırmada mı yanıtlandığını büyük ölçüde etkiler.\n\n### Okunabilir çıktı hata ayıklamayı kısaltır (ve daha hızlı öğretir)\n\nNet başarısızlık çıktısı sessiz bir verimlilik çarpanıdır. Tam olarak neyin değiştiğini vurgulayan bir diff, kodunuza işaret eden bir stack trace (çerçeve içi ayrıntılar yerine) ve gerçek girdileri içeren bir mesaj hatayı hızlı bir düzeltmeye dönüştürür.\n\nTersi de gerçek: şifreli assertion'lar, eksik bağlam veya kullanışlı satırı en alta gömen log'lar hata ayıklama süresini artırır ve yeni ekip üyelerinin öğrenmesini yavaşlatır. Zamanla insanlar test hatalarını "başkasının sorunu" olarak görür çünkü anlaması çok maliyetlidir.\n\n### İyi hata mesajları suçlamayı azaltır ve işbirliğini hızlandırır\n\nNeden yanlış olduğunu açıklayan hatalar daha sakin bir kültür yaratır. "Beklenen 200, alınan 500" bir başlangıçtır; "/checkout'dan geçerli bir sepet ile 200 bekleniyordu; 500 alındı (PaymentMapper'da NullReference)" ise eyleme geçirilebilir.\n\nMesaj niyeti ve temel durumu (kullanıcı tipi, feature flag, çevre varsayımları) içerdiğinde ekip arkadaşları tartışmak yerine birlikte düzeltmeye başlayabilir.\n\nPratik bir kural: bir başarısızlık mesajı testi yazmayan biri tarafından anlaşılamıyorsa, kesintiler, savunmacılık ve yavaş incelemeler üretecektir.\n\n### Konvansiyonlar: adlandırma, yapı, raporlama\n\nÇerçeveler genellikle desenleri teşvik eder—bunu standartlaştırmak için kullanın:\n\n- Adlandırma: Niyet-öncelikli isimleri tercih edin (ör. checkout_returns_200_for_valid_card) belirsiz isimler (testCheckout) yerine.\n- Yapı: Herkesin testleri hızlıca tarayabilmesi için Arrange/Act/Assert düzenini kullanın.\n- Raporlama: Hata durumunda neyin yazdırılacağı konusunda anlaşın (anahtar ID'ler, URL'ler, payload parçacıkları ve gereken minimal loglar). Raporları tutarlı tutun ki CI hataları tanıdık olsun.\n\n### Kırılgan testler güveni aşındırır\n\n"Bazen" başarısız olan testlerden daha hızlı itibar zedelesi yoktur. Flakiness ekipleri kırmızı build'leri görmezden gelmeye, işleri yeniden çalıştırıp yeşil olana kadar beklemeye ve şüpheyle dağıtmaya alıştırır. Bir kere bu alışkanlık oluşursa, gerçek hatalar bile isteğe bağlı muamelesi görür.\n\nKırılgan testleri kültürel borç olarak ele alın: hızla karantinaya alın, açıkça izleyin ve "düzelt veya sil" ortak beklentisi koyun—çünkü güvenilir sinyaller güvenilir iş birliğinin temelidir.\n\n## Onboarding: Çerçeve Öğretici Bir Araçtır\n\nYeni bir mühendis, takımın değerlerini herhangi bir slayt destesinden daha hızlı ilk yeşil build'ten öğrenir. Test çerçeveleri konvansiyonlarıyla sessizce "burada işleri nasıl yaptığımızı" öğretiyor: testlerin nerede olduğu, nasıl adlandırıldığı, hataların nasıl okunduğu ve basit bir assertion yazmanın ne kadar törensel olduğu.\n\n### Bilişsel yükü azaltan (veya artıran) konvansiyonlar\n\nNet varsayılanlara sahip çerçeveler onboarding'i kolaylaştırır çünkü yeni gelenler desenleri kendileri icat etmek zorunda kalmaz. Konvansiyonlar belirsiz veya takım çerçeve ile mücadele ediyorsa yeni personel ilk haftasını "bunu nereye koyarım?" sorusunu sorarak geçirir, ürünü öğrenerek değil.\n\nErken standartlaştırmaya değer ortak desenler:\n\n- Setup/teardown: test verisi oluşturma ve yan etkileri temizleme için tek bir yer.\n- Fixture'lar: testleri kısa ve okunabilir tutan tekrar kullanılabilir "bilinen iyi" objeler.\n- Yardımcılar ve paylaşılan araçlar: giriş yapma, zaman kontrolü, factory'ler ve API stub'ları için küçük ve kasıtlı bir araç seti—büyüyen bir "test utils" karmasına dönüşmesini önleyin.\n\n### Başlangıç şablonu repo + "ilk test" kontrol listesi\n\nOnboardingi somutlaştırmak için bir başlangıç şablon deposu (veya monorepo içinde bir klasör) oluşturun; içinde şunlar olsun:\n\n- Beklediğiniz katmanlar için minimal bir örnek test (birim/entegrasyon).\n- Ön yapılandırılmış komutlar: test, test:watch, test:ci.\n- Test dosyaları için kararlı lint/format ayarları.\n- Kısa bir README ve /engineering/testing-standards sayfasına yönlendirme.\n\nYeni gelen için ilk test kontrol listesi:\n\n1. Testleri yerelde ve watch modunda çalıştırın.\n2. Yakın zamanda yapılan bir değişikliğe küçük bir birim testi ekleyin.\n3. Bilerek kırın ve başarısızlık çıktısını görün.\n4. Düzeltin, bir branch'e push edin ve CI'yi izleyin.\n4. İnceleme isteyin ve geri bildirime yanıt verin.\n\n### Dokümantasyon ve örnekler onboarding'i hızlandırır\n\nYüksek kaliteli çerçeve dokümanları ve topluluk örnekleri kabile bilgisini azaltır. Açık başarısızlık mesajları, güncel rehberler ve sağlıklı bir ekosisteme sahip çerçeveleri tercih edin—sonra en iyi "nasıl yapılır" sayfalarını dahili dokümanlardan (/engineering/testing-standards) doğrudan bağlayın ki yeni gelenler aramak zorunda kalmasın.\n\n## Kod İnceleme Normları Test Beklentileri ile Belirlenir\n\nKod inceleme sadece stil ve doğrulukla ilgili değildir—bir ekipte "iyi"nin ne demek olduğunu müzakere ettiği yerdir. Test çerçeveleri bu müzakereyi sessizce şekillendirir çünkü test ekleme, çalıştırma ve anlama kolaylığını tanımlarlar.\n\n### Testler konuşmayı nasıl yönlendirir\n\nİnceleyenler bir testi hızlıca okuyup güvenebilirlerse, inceleme yorumları "Bu kırar mı?" tartışmalarından "Bu durumda ne oluyor, göster"e kayar. İyi testler ortak bir dil haline gelir: kenar vakaları belgelendirir, niyeti netleştirir ve riski görünür kılar.\n\nZamanla ekip testleri değişikliğin bir parçası olarak görmeye başlar, isteğe bağlı bir eklenti olarak değil. Testsiz bir pull request daha fazla geri dönüş, daha fazla "ya şöyle olursa" sorusu ve daha uzun onay döngüleri davet eder.\n\n### Ergonomi, inceleyicilerin test isteme sıklığını değiştirir\n\nÇerçeve kurulumu sancılı yapıyorsa—yavaş koşma, kafa karıştıran mock'lar, kırılgan fixture'lar—inceleyenler test talep etmekten kaçınır çünkü bunun PR'yi durduracağını bilirler. Hızlı ve keyifliyse, "Lütfen bir test ekle" normal ve düşük maliyetli bir yorum olur.\n\nBu nedenle geliştirici deneyimi kültürel bir meseledir: doğru şeyi yapmak ne kadar kolaysa, ekip onu o kadar tutarlı biçimde bekler.\n\n### Pratik inceleme yönergeleri\n\nBasit bir norm seti incelemeleri odaklı tutar:\n\n- Kırabilecek olanı test et: iş kuralları, karmaşık kenar durumları ve hata düzeltmeleri (regresyon testi ekleyin).\n- Açık olanı test etmeyin: çerçeve içi davranış, kütüphane davranışı veya önemsiz getter/setter'lar—bunlar gürültü ekler.\n- Kararlı sinyalleri tercih edin: implementasyon detayları yerine sonuçları ve kullanıcı görünür davranışı doğrulayın.\n- Bir PR, bir hikaye: testler değişikliği açıklamalı, ikinci bir proje haline gelmemeli.\n\n### Paylaşılan sahiplik, ayrı bir hat değil\n\nSağlıklı ekipler testleri üretim kodu gibi ele alır: herkes yazar, herkes düzeltir ve başarısız testler kimin sorumluluğu olduğuna bakılmaksızın merge'i engeller. Bu paylaşılan sorumluluk, test otomasyonunun bir QA kontrol noktası değil günlük bir alışkanlık olmasını sağlar.\n\n## CI Entegrasyonu Testleri Sosyal Bir Sözleşmeye Dönüştürür\n\nBir test çerçevesi CI hattınıza bağlandığında, testler "benim yerel görüşüm" olmaktan çıkar ve "ekibin ortak anlaşması" haline gelir. Her pull request aynı kontrolleri aynı ortamda çalıştırır ve sonuç herkesin görebileceği şekilde görünür. Bu görünürlük sorumluluğu değiştirir: hatalar özel rahatsızlıklar değil, tüm ekibin hissettiği engeller olur.\n\n### Kapama (gating) standartları varsayılan haline getirir\n\nÇoğu ekip CI gating'i "tamamlanmış"ın ne demek olduğunu tanımlamak için kullanır.\n\nBir çerçevenin CI ile temiz entegrasyonu, gerekli kontrolleri (ör. birim testleri, linting ve minimal entegrasyon suite'i) zorlamayı kolaylaştırır. Kapsam sinyalleri veya statik analiz eşiklerini kalite kapıları olarak ekleyerek iş akışına değerleri kodlarsınız: "güveni azaltan kodu merge etmiyoruz."\n\nKapsam konusunda dikkatli olun. Eğilim veya koruyucu bir işaret olarak faydalıdır ama anlamlı testi kanıtlamaz. Bir gösterge, skor tahtası değil.\n\n### Kırılgan testler sürüm davranışını hızlıca değiştirir\n\nKırılgan testler sadece dakikaları boşa harcamaz; tüm hattın güvenini aşındırır. İnsanlar kırmızı build'lerin "çoğu zaman kendiliğinden düzelmeyeceğini" öğrendiklerinde, parmaklar çaprazlanarak merge eder, sürümleri erteler veya kapıları atlar. Olay esnasında, kırılgan suite'ler resmi karışık hale getirir: değişikliğin güvenli mi yoksa rollback mi gerektirdiğini çabuk söylemek zorlaşır.\n\nÇerçeveniz flakiness'i teşhis etmeyi zorlaştırıyorsa (zayıf raporlama, yetersiz retry'ler, belirsiz loglar), riskin normalleşmesine sessizce katkıda bulunur.\n\n### Ayrık pipeline'lar: hızlı kontroller vs daha derin güven\n\nPratik bir desen pipeline'ları amaçlarına göre ayırmaktır:\n\n- Her PR için hızlı kontroller: hızlı birim testleri ve yüksek sinyalli küçük entegrasyon testleri\n- Gecelik (veya planlı) suite'ler: daha geniş entegrasyon/E2E kapsamı, çapraz tarayıcı/cihaz çalıştırmaları, daha uzun senaryolar\n\nBu, geri bildirimi sıkı tutarken derinlikten de vazgeçmemenizi sağlar. En iyi çerçeve-CI entegrasyonu, "doğru şey"i en kolay yapılacak şey haline getirendir.\n\n## Test Stratejisi: Çerçeveler Piramidi Yukarı mı Aşağı mı Eğiyor\n\n"Test piramidi" hızlı, odaklı testleri daha az sayıda gerçekçi, daha yavaş testle dengelemek için bir yoldur. Çerçeveler bazı test türlerini kolay, diğerlerini sancılı hâle getirerek bu dengeyi sessizce yönlendirir.\n\n### Üç seviye (basit dille)\n\nBirim testleri küçük bir kod parçasını (ör. bir fonksiyon) izole olarak kontrol eder. Genellikle en hızlıdır ve sık çalıştırılmaya uygundur.\n\nEntegrasyon testleri birden fazla parçanın birlikte çalışmasını kontrol eder (ör. API + veritabanı veya bir servis + kuyruk). Birim testlerinden daha yavaştır ama "bağlantı" sorunlarını yakalar.\n\nUçtan uca (E2E) testleri gerçek kullanıcı akışlarını tüm sisteme karşı simüle eder (genellikle bir tarayıcı üzerinden). Yüksek güven sağlar ama en yavaş ve en kırılgandır.\n\n### Çerçeveler piramidinizi nasıl eğer\n\nSeçtiğiniz çerçeve E2E testlerini keyifli hale getiriyorsa—mükemmel tarayıcı aracı, otomatik beklemeler, görsel runner'lar, basit kurulum—davranış olarak E2E testlerine fazla kayabilirsiniz. Sonuç, ekiplerin çalıştırmaktan kaçındığı yavaş bir suite ve "testler kırılgan" kültürüdür.\n\nDiğer yandan, birim test çerçevesi ağır mock araçlarıyla geliyorsa ekipleri "her şeyi mock'la"ya itebilir; bu durumda gerçek entegrasyonlar kırıldığında testler yeşil kalır.\n\n### Basit bir tahsis kestirimi\n\nBirçok ekip için pratik başlangıç noktası:\n\n- ~%70 birim testleri (mantık için ucuz kapsam)\n- ~%20 entegrasyon testleri (sözleşme ve bağlantı sorunlarını yakalamak için)\n- ~%10 E2E testleri (kritik kullanıcı yolculuklarını korumak için)\n\nRisk bazlı ayarlayın, ama E2E'yi varsayılan değil, özenle seçilmiş iş kritik yollar olarak görün.\n\n### Piramidiniz ters dönmüşse uyarı işaretleri\n\n- "Sadece E2E": build'ler yavaş, testler zamanlama kaynaklı fail oluyor ve küçük UI değişiklikleri alakasız kontrolleri bozuyor.\n- "Her şeyi mock'la": testler yeşil ama staging kırmızı; hatalar şaşırtıcı çünkü testler gerçek sınırları hiç zorlamadı.\n\n## Bakımı Kolay Testler Sürdürülebilir Mühendisliği Teşvik Eder\n\nTest otomasyonunda sürdürülebilirlik üç şeye bağlıdır: okunabilirlik (herkes testin neyi kanıtladığını anlayabilmeli), kararlılık (testler rastgele nedenlerle başarısız olmamalı) ve değişiklik kolaylığı (küçük ürün değişiklikleri tüm suite'i yeniden yazmayı gerektirmemeli).\n\nBir çerçeve bu nitelikleri kolay hale getiriyorsa, ekipler insanları yakmadan kaliteyi koruyan alışkanlıklar geliştirir.\n\n### Testleri basit tutan desenler\n\nİyi çerçeveler ekipleri niyeti gizlemeden tekrar kullanıma yönlendirir. Tekrarı azaltan birkaç desen:\n\n- Ortak ön koşulları kurmak için fixture'lar (kullanıcılar, izinler, seed verilere dair).\n- Mantıklı varsayılanlarla nesneler yaratan factory/builder'lar; her test sadece önemli olanı ezebilir.\n- Tekrarlanan eylemler için helper'lar (ör. "sipariş oluştur", "giriş yap", "makale yayınla"), teknik adımlar yerine iş adımları gibi adlandırılmış.\n\nKültürel etkisi ince ama güçlüdür: testler dokümantasyon gibi okunur ve yeni değişiklikler bir fixture veya factory güncellemesi ile birçok testi tutarlı şekilde güncelleyebilir.\n\n### Takımı tüketen anti-pattern'ler\n\nBazı uygulamalar kırılgan bir suite ve test hatalarına karşı sinik bir tutum yaratır:\n\n- Paylaşılan değiştirilebilir durum (bir testin kurulumu diğerine sızar), aralıklı başarısızlıklara yol açar.\n- Aşırı mock'lama mock kurulumunu test eden testler yaratır, gerçek davranışı test etmez; sürüm güveni düşer.\n- Kırılgan seçiciler ve aşırı spesifik assertion'lar zararsız UI veya metin değişikliklerinde kırılır.\n\n### Test refaktörünü gerçek iş olarak görün\n\nSürdürülebilir mühendislik test refactor'larını üretim refactor'ı gibi ele alır: planlı, gözden geçirilmiş ve sürekli—"sonra temizlik" değil. Testleri sürdürülebilir hale getirmek teslimatın bir parçası olmalı; böylece CI hattınız arka plan gürültüsü değil güvenilir bir sinyal olur.\n\n## Ölçtüğünüz Şey Değer Verdiğiniz Şey Olur\n\nTest çerçeveleri sadece kontrolleri çalıştırmaz—bazı sinyalleri görünür kılar, bazılarını yok saymayı kolaylaştırır. Bu sinyaller PR'larda, CI özetlerinde ve ekip panolarında görünmeye başlayınca, sessizce öncelikler haline gelir. Bu gerçekten kaliteyi işaret ediyorsa faydalıdır; yanlış davranışları ödüllendiriyorsa zararlı olur.\n\n### Metrikler: faydalı ama manipüle edilmesi kolay\n\nTek bir sayı kararları basitleştirebilir ("testler yeşil"), ama aynı zamanda kötü teşvikler de yaratabilir ("yavaş suite'leri atlayarak daha hızlı göndermek" veya "hiçbir şey doğrulamayan birim testleri şişirmek"). İyi metrikler sağlığı tarif eder; kötü metrikler hedef olur.\n\n### Davranışı iyileştiren pratik metrikler\n\nAğırlıksız bir set genellikle karmaşık bir puan kartından daha etkilidir:\n\n- Test çalışma süresi (genel ve suite bazında): geri bildirimin çok yavaş olduğu yerleri gösterir.\n- Kırılganlık oranı: güven sorunlarını ortaya çıkarır. Eğer geliştiriciler retry bekliyorsa incelemeler ve sürümler yavaşlar.\n- Kaçan hatalar (sürüm sonrası bulunan bug'lar): test yatırımının müşteri etkisine bağlanmasını sağlar.\n- Test hatalarını düzeltme ortalaması (MTTR): CI bozulduğunda ekibin güveni ne kadar çabuk geri getirdiğini ölçer.\n\n### Kapsamı bir ipucu olarak kullanın, kanıt olarak değil\n\nKapsam size tamamen testsiz alanları gösterebilir; bu değerlidir. Ancak anlamlı testlerin var olduğunu veya kritik davranışların korunduğunu kanıtlayamaz. Kapsamı kör noktaları bulmak için kullanın, sonra testlerin uygulama detayları yerine sonuçları doğrulayıp doğrulamadığını değerlendirin.\n\n### Panolar ve sahiplik "test sağlığını" gerçek tutar\n\nPanoları küçük ve görünür tutun (CI özeti + basit haftalık eğilim). Net sahiplik atayın: dönen bir "test sağlığı" sorumlusu veya alan/ekip bazlı sahiplik. Amaç hızlı kararlar: kırılganlığı düzeltmek, suite'leri hızlandırmak ve kırık testlerin normalleşmesini engellemek.\n\n## Ekibinize Uyan Bir Çerçeve Seçmek\n\nBir test çerçevesi sadece teknik bir tercih değildir—insanların nasıl yazdığı, incelediği ve koda güvendiği beklentileri belirler. "En iyi" çerçeve, takımınızın gerçek teslim tarihlerinde az sürtüşmeyle tutarlı olarak kullanabileceği olanıdır.\n\n### Pratik kriterler (günlük hissettikleriniz)\n\nÖzellik listelerine bakmayı bırakıp uyuma odaklanın:\n\n- Dil uyumu: Ana uygulama dili ve runtime ile uyumlu mu?\n- Ecosystem desteği: Olgun dökümantasyon, topluluk örnekleri, eklentiler, raporlayıcılar, mock araçları.\n- IDE entegrasyonu: Testleri debug etme, hatalara atlama, tek bir testi hızlı çalıştırma.\n- Öğrenme eğrisi: Yeni bir çalışan ilk haftasında iyi bir test yazabiliyor mu?\n\n### Teknik olmayan kriterler (sürdürülebilir kılanlar)\n\nBu faktörler sıklıkla seçimin uzun ömürlü olup olmayacağını belirler:\n\n- Takım deneyimi: Zaten çerçeveye hakim kişiler var mı?\n- İşe alım havuzu: Adaylar bunu bilmeyecekse yeniden eğitmeniz gerekir mi?\n- Uzun dönem destek: Yayın sıklığı, bakım ekibi, stack ile uyumluluk ve yükseltme yolu.\n\n### Karar vermeden önce küçük bir pilot çalıştırın\n\nTemsilci bir servis veya modül seçin ve 1–2 hafta içinde 2–3 seçeneği karşılaştırın. Ölçün:\n\n- Kurulum süresi: sıfırdan anlamlı ilk teste kadar süre.\n- Kırılganlık: testler ürün değişiklikleriyle ilgisiz nedenlerle fail oluyor mu?\n- Geliştirici memnuniyeti: kısa anket: "Yazması, çalıştırması ve debug etmesi kolay mıydı?"\n\n### Karar kontrol listesi + pişman etmeyecek bir geçiş planı\n\nKontrol listesi: hızlı yerel çalışma, net başarısızlık çıktısı, stabil CI entegrasyonu, iyi mock/fixture desteği, paralelleştirme, aktif bakım ve takım tanıdıklığı.\n\nGeçiş taslağı: önce yeni kodda kullanın, eski testleri CI'de çalışır tutun, paylaşılan helper/adapter ekleyin, en çok değişen alanları önce taşıyın ve eski çerçeveyi salt okunur yapacağınız bir bitiş tarihi belirleyin.\n\n## Benimseme Planı: Kültür Değişikliğini Kalıcı Hale Getirin\n\nYeni bir test çerçevesi benimsemek bir araç değişimi değil, paylaşılan beklentiler belirlemektir. Amaç "doğru şeyi" kolay, varsayılan hale getirmektir.\n\n### Gerçekten işe yarayan bir dağıtım planı\n\nBir sayfaya sığacak hafif bir standartla başlayın: adlandırma kuralları, test yapılandırması, ne zaman mock yapılacağı ve takım için "iyi kapsam" ne demek.\n\nHiç kimsenin sıfırdan başlamaması için şablonlar ekleyin: örnek test dosyası, ortak fixture için yardımcı ve CI iş tanımı. Ardından 30–45 dakikalık kısa eğitimler düzenleyin; odak noktasını "çerçeveyi nasıl kullanacağız" üzerine kurun, tüm özellikleri öğretmeye çalışmayın.\n\nKademeli olarak benimseyin:\n\n- Yeni kod hemen yeni çerçeveyi kullanır.\n- Eski koda dokunulduğunda "daha iyi bırak" ilkesiyle bir veya iki testi migrate edin.\n- Eski çerçevede yeni testlerin yazılmasının duracağı bir hedef tarih belirleyin.\n\n### Miras testleri ve karışık çerçeveler (karmaşa olmadan)\n\nKarışık çerçeveler sınırlar açık olduğunda sorun yaratmaz. CI'de çalıştırıcıları ayrı tutun, sonuçları birlikte raporlayın ve hangi alanların "legacy" olduğunu belgeleyin. Büyük çaplı yeniden yazmalardan kaçının; bunun yerine güvenlik artıran migrasyonlara öncelik verin (kırılgan suite'ler, yavaş suite'ler, kritik yollar).\n\nHer ikisini bir süre tutmanız gerekiyorsa, ortak bir kural belirleyin: hangi tarafta olursa olsun hatalar merge'i engeller.\n\n### Bir test oynama kitabı ve referans proje oluşturun\n\nBasit bir playbook sayfası yayınlayın (ör. /docs/testing-playbook) ile:\n\n- Testleri yerelde nasıl yazıp çalıştıracağınız\n- Birim vs entegrasyon testleri için örnekler\n- Ortak sorun giderme ve timeout ipuçları\n\nNet bir proje yapısı tartışmayı azaltır:\n\n```

/tests /unit /integration /fixtures /src ...

\nÇerçeveler, açık normlar, kolay şablonlar, tutarlı CI zorlamaları ve mükemmelliğe değil ilerlemeye odaklanan bir geçiş yolu ile birlikte kültürü pekiştirir.\n\n### Koder.ai nerede "iyi varsayılanları" gerçeğe dönüştürmeye yardımcı olabilir\n\nAlışkanlıkları değiştirmeye çalışıyorsanız en hızlı kazanç genellikle kurulum sürtüşmesini azaltmaktır. **Koder.ai** kullanan ekipler genellikle küçük bir "altın yol" proje yapısı ve test komutları (ör. `test`, `test:watch`, `test:ci`) oluşturarak başlar, sonra sohbet içinde çerçeve konvansiyonlarını ekip playbook'una uyan şekilde yineleyip düzenlerler.\n\nKoder.ai, sohbet odaklı iş akışıyla tam web/sunucu/mobil uygulamalar oluşturup kaynak kodu depoya aktarabildiği için bir çerçeve pilotunu (CI kurulum dahil) prototiplemek için pratik bir yoldur. Araç seçimi yine önemlidir, ama doğru şeyi yapmanın maliyetini düşürmek standartları kültüre dönüştürür.