Otomatik testler genellikle testleri bulmak ve çalıştırmak için bir komut dosyasını manuel olarak çalıştırabilir veya test çerçevesinden bir yardımcının (genellikle test çalıştırıcısı olarak adlandırılır) yardımıyla çalıştırılabilir. Bununla birlikte, komut dosyalarınızı her zaman manuel olarak çalıştırmak istemeyebilirsiniz. Geliştirme yaşam döngüsünün farklı noktalarında geri bildirim ve güven sağlayabilecek çeşitli testler yapabilirsiniz.
Ön koşul komut dosyası
Web projeleri genellikle npm, pnpm, Bun veya benzeri bir yöntemle ayarlanan bir yapılandırma dosyasına (package.json dosyaları) sahiptir. Bu yapılandırma dosyasında projenizin bağımlılıkları, diğer bilgiler ve yardımcı komut dosyaları yer alır. Bu yardımcı komut dosyalarında projenizi nasıl oluşturacağınız, çalıştıracağınız veya test edeceğiniz yer alabilir.
package.json içinde, testlerinizi nasıl çalıştıracağınızı açıklayan test adlı bir komut dosyası eklemeniz gerekir. npm veya benzer bir araç kullanılırken "test" komut dosyasının özel bir anlamı olduğu için bu önemlidir.
Bu komut dosyası, istisna oluşturan tek bir dosyayı (node tests.js gibi) işaretleyebilir ancak bunu köklü bir test çalıştırıcısına işaret etmek için kullanmanızı öneririz.
Test çalıştırıcınız olarak Vitest'i kullanıyorsanız package.json dosyanız aşağıdaki gibi görünür:
{
"name": "example-project",
"scripts": {
"start": "node server.js",
"test": "vitest --run"
}
}
npm test bu dosyayla çalıştırıldığında, Vitest'in varsayılan test grubu bir kez çalıştırılır. Vitest'te varsayılan değer, ".test.js" veya benzeri ile biten tüm dosyaları bulup çalıştırmaktır. Seçtiğiniz test çalıştırıcısına bağlı olarak komut biraz farklı olabilir.
Bu kurs boyunca, örnekler için gittikçe yaygınlaşan Vitest'i kullanmayı seçtik. Bu karar hakkında daha fazla bilgiyi Test çalıştırıcı olarak Vitest bölümünde bulabilirsiniz. Ancak test çerçeveleri ve çalıştırıcıların (hatta diller arasında) ortak bir dile sahip olma eğiliminde olduğunu unutmamak gerekir.
Manuel test çağrısı
Bir kod tabanı üzerinde aktif olarak çalışırken otomatik testlerinizi manuel olarak tetiklemek (önceki örnekte verilmiş npm test kullanmak gibi) pratik olabilir.
Bir özellik geliştirirken o özellik için test yazmak, özelliğin nasıl çalışması gerektiği hakkında fikir edinmenize yardımcı olabilir. Bu, test odaklı geliştirme (TDD) kavramına değinmektedir.
Test yürütücüler genellikle testlerinizin bazılarını veya tümünü çalıştırmak için çağırabileceğiniz kısa bir komuta ve muhtemelen siz kaydederken testleri tekrar çalıştıran bir izleyici moduna sahiptir. Bunların hepsi yeni bir özellik geliştirirken kullanışlı seçeneklerdir ve hızlı geri bildirimle yeni bir özelliği, testlerini veya her ikisini birden yazmayı kolaylaştıracak şekilde tasarlanmıştır. Örneğin Vitest, varsayılan olarak gözlemci modunda çalışır: vitest komutu değişiklikleri izler ve bulduğu testleri yeniden çalıştırır. Testlerinizi yazarken bu pencereyi başka bir pencerede açık bırakmanızı öneririz. Böylece, testlerinizi geliştirirken testleriniz hakkında hızlı geri bildirimler alabilirsiniz.
Bazı çalıştırıcılar, kodunuzda testleri only olarak işaretlemenize de olanak tanır. Kodunuz only testleri içeriyorsa testi çalıştırdığınızda yalnızca bu testler tetiklenir. Böylece test geliştirme daha hızlı ve daha kolay giderilir. Tüm testleriniz hızlı bir şekilde tamamlansa bile only kullanmak, ek yükünüzü azaltabilir ve üzerinde çalıştığınız özellik ya da testle ilgisi olmayan testler yürütmenin getirdiği dikkati ortadan kaldırabilir.
Küçük projelerde, özellikle de yalnızca bir geliştiricisinin bulunduğu projelerde, kod tabanınızın tüm test paketini düzenli olarak çalıştırma alışkanlığı edinmek de isteyebilirsiniz. Bu, özellikle testleriniz küçükse ve hızlı bir şekilde tamamlandıysa (tüm testlerinizde birkaç saniyeden uzun sürmeyecekse) faydalıdır. Bu nedenle, devam etmeden önce her şeyin çalıştığından emin olabilirsiniz.
Testleri, gönderim öncesi veya inceleme sürecinin parçası olarak çalıştırma
Birçok proje, kod tekrar main dalıyla birleştirilirken kod tabanının doğru şekilde çalıştığını onaylamayı seçer. Test konusunda yeniyseniz, ancak geçmişte açık kaynak projelerine katkıda bulunduysanız pull isteği (PR) sürecinin bir bölümünün projenin tüm testlerde başarılı olduğunu onaylandığını, yani heyecan verici yeni katkınızın mevcut projeyi olumsuz etkilemediğini fark etmiş olabilirsiniz.
Testlerinizi yerel olarak çalıştırırsanız projenizin online deposu (örneğin, GitHub veya başka bir kod barındırma hizmeti) testlerinizin başarılı olup olmadığını bilemez. Bu nedenle, ön gönderme görevi olarak test çalıştırmak, tüm katkıda bulunanlara her şeyin yolunda gittiğini açıklar.
Örneğin GitHub, bunları GitHub İşlemleri aracılığıyla ekleyebileceğiniz "durum kontrolleri" olarak adlandırır. GitHub İşlemleri, temelde bir tür testtir: İşlemin başarılı olabilmesi için her adımın başarılı olması (başarısız olmamalı veya bir Error atması) gerekir. Bir projenin tüm PR'lerine Actions uygulayabilirsiniz ve bir proje, kod eklemeden önce İşlemlerin geçmesini gerektirebilir. GitHub'ın varsayılan Node.js işlemi, adımlarından biri olarak npm test'yi çalıştırır.
Bu test yaklaşımı, testlerini başarıyla çalıştırmayan kodları kabul etmeyerek kod tabanınızın her zaman "yeşil" olmasını sağlamaya çalışır.
Sürekli Entegrasyon kapsamında test çalıştırma
Yeşil PR'niz kabul edildikten sonra çoğu kod tabanı, önceki PR'ye göre değil, projenizin main dalına göre tekrar test yapar. Bu durum hemen veya düzenli olarak (örneğin, saatlik veya gecelik) gerçekleşebilir. Bu sonuçlar genellikle projenin genel durumunu gösteren Sürekli Entegrasyon (CI) kontrol panelinin bir parçası olarak gösterilir.
Bu CI adımı, özellikle kod tabanları küçük projeler için gereksiz görünebilir. İnceleme sırasında geçilen testler bu nedenle bir değişiklik olduğunda geçmelidir. Ancak bu her zaman geçerli değildir! Testleriniz yeşil sonuçlar verdiğinde bile aniden başarısız olabilir. Bunun bazı nedenleri şunlardır:
- Bazen ırk durumu olarak da bilinen bazı değişiklikler "bir seferde" kabul edildi ve birbirlerini hafif ve test edilmemiş şekillerde etkiliyorlar.
- Testleriniz tekrarlanabilir değildir veya "kesintisiz" kodu test eder. Kod değişikliği olmadan hem başarılı hem de başarısız olabilirler.
- Bu durum, kod tabanınızın dışındaki sistemlere ihtiyaç duymanız durumunda gerçekleşebilir. Bir proxy için
Math.random() > 0.05olup olmadığını test ettiğinizi düşünün. Bu, %5 oranında rastgele başarısız olur.
- Bu durum, kod tabanınızın dışındaki sistemlere ihtiyaç duymanız durumunda gerçekleşebilir. Bir proxy için
- Uçtan uca testler gibi bazı testler her halkla ilişkilerde çok maliyetli ya da pahalıdır (bundan daha fazla ayrıntı için otomatik test türlerinde daha fazla bilgi verilmiştir) ve her zaman uyarı göstermeden zaman içinde bozulabilir.
Bu sorunların hiçbirinin üstesinden gelmek imkansız değildir ama testin ve genel anlamda yazılım geliştirmenin hiçbir zaman kesin bir bilim olmadığının farkına varmaya değer.
Geri dönme ile ilgili bir ara
Testler sürekli entegrasyonun bir parçası olarak çalıştırıldığında ve testler, durum kontrolünün bir parçası olarak çalıştırıldığında bile, derleme "kırmızı" durumda veya testlerin başarısız olduğu anlamına gelen başka bir durumla karşılaşabilir. Daha önce de belirtildiği gibi bu, test gönderimindeki yarış koşulları veya güvenilir olmayan testler gibi çeşitli nedenlerle gerçekleşebilir.
Daha küçük projelerde içgüdüleriniz duruma bir kriz gibi bakıyor olabilir. Her şeyi durdurun, geri çekin veya sorunlu değişikliği geri alın ve bilinen iyi duruma geri dönün. Bu geçerli bir yaklaşım olabilir ancak testin (ve genel olarak yazılımın) tek başına bir hedef değil, sonuca ulaşmak için bir araç olduğunu unutmamak önemlidir. Muhtemelen hedefiniz tüm testlerin başarılı olmasını değil, yazılım yazmaktır. Bunun yerine, zarar veren değişikliği takip edip başarısız testleri düzelten başka bir değişiklikle ileriye alabilirsiniz.
Öte yandan, sürekli bozulan büyük projelere görmüş veya üzerinde çalışmış olabilirsiniz. Daha da kötüsü, büyük projede geliştiricilerde alarm yorgunluğuna neden olacak kadar sık kopan güvenilir bir test vardır. Bu, çoğu zaman liderlerin çözmesi gereken varoluşsal bir sorundur. Hatta bu testler, "geliştirmenin önüne geçmek" olarak görüldüğü için devre dışı bırakılabilir.
Bu sorunun hızlı bir çözümü yoktur, ancak yazma testleri daha güvenli hale gelmeye (yetenek geliştirme) yardımcı olabilir ve hataların daha kolay bir şekilde tanımlanabilmesi için testlerin kapsamını daraltmayı (basitleştirme) sağlayabilir. Bileşen testi veya entegrasyon testi sayısının artması (Otomatik test türleri türlerinde daha fazla bilgi), bakımı zor olan ve her şeyi aynı anda yapmaya çalışan büyük bir uçtan uca teste kıyasla daha fazla güven sağlayabilir.
Kaynaklar
Öğrendiklerinizi sınayın
npm ve benzer programların test sırasında aradığı özel komut dosyasının adı nedir?