Testlerin çalıştırıldığı yer

Otomatik testler genellikle bir komut dosyası manuel olarak çalıştırılarak veya genellikle test çalıştırıcısı olarak adlandırılan bir test çerçevesinden gelen yardımcı testler. Yine de komut dosyalarınızı her zaman manuel olarak çalıştırmak zorunda kalmayabilirsiniz. Çeşitli testler yaparak geri bildirim ve katkı sağlayabilirsiniz. güvenlerini ölçtüğünden emin olun.

Ön koşul komut dosyası

Web projelerinde genellikle bir yapılandırma dosyası (package.json dosyası) bulunur. npm, pnpm, Bun veya benzeri bir sisteme göre ayarlanır. Bu yapılandırma dosyası ve diğer bilgilerin yanı sıra yardımcı komut dosyaları da oluşturacaksınız. Bu yardımcı komut dosyaları projenizin nasıl oluşturulacağını, çalıştırılacağını veya test edileceğini içerebilir.

package.json içinde şunları açıklayan test adlı bir komut dosyası eklemeniz gerekir: nasıl yapılacağını göstereceğim. Bu önemlidir, çünkü npm veya benzer bir "test" komut dosyasının özel bir anlamı vardır. Bu komut dosyası, istisnaya neden olan tek bir dosyayı gösterebilir: node tests.js gibi bir şeydir. Ancak bunu yaparken test çalıştırıcısı var.

Test koşucusu olarak Vitest'i kullanıyorsanız package.json dosyası şöyle 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. İçinde Vitest, varsayılan olarak ".test.js" ile biten tüm dosyaları bulmaktır veya benzer ve bunları çalıştırın. Size komut dosyası biraz farklı olabilir.

Biz testler için gittikçe popüler olan bir test çerçevesi olan Vitest'i bazı örnekler vereceğim. Web sitemiz g.co/newsinitiative/labs üzerinden bu kararı test çalıştırıcısı olarak Vitest'te bulabilirsiniz. Ancak test çerçevelerinin ve çalıştırıcılarının, genellikle ortak bir dile sahip olur.

Manuel test çağrısı

Otomatik testlerinizi manuel olarak tetiklemek (örneğin,npm test önceki örnek) kod tabanı üzerinde aktif olarak çalışırken sizin için pratik olabilir. Bir özelliği geliştirirken ilgili testler yazmak, nasıl çalışması gerektiğine dair bir fikir edinir; çünkü bu, teste dayalı geliştirme (TDD) ile ilişkilidir.

Test çalıştırıcıları genellikle bazı işlemleri çalıştırmak için çağırabileceğiniz tüm testlerinizi ve eğer tasarruf ettikçe testleri yeniden çalıştıran bir izleme modu gerekir. Bunların hepsi yeni bir özellik geliştirirken kullanışlı seçeneklerdir yeni bir özelliği, testlerini veya her ikisini birden yazmayı kolaylaştırmak için tasarlanmış hızlı geri bildirim sağlar. Örneğin Vitest, varsayılan olarak izleyici modunda çalışır: vitest komutu değişiklikleri izler ve bulduğu testleri yeniden çalıştırır. Biz testleri yazarken bunu başka bir pencerede açık bırakmanızı öneririz. Böylece, geliştirdikçe testleriniz hakkında hızlı geri bildirim alın.

Bazı çalıştırıcılar, kodunuzda testleri only olarak işaretlemenize de olanak tanır. Kodunuz only testlerini içeriyorsa testi çalıştırdığınızda yalnızca bu testler tetiklenir, ve sorunları gidermesi kolaylaşır. Tüm teslimatlarınız testler hızla tamamlanır. only kullanmak ek yükünüzü azaltabilir ve üzerinde çalıştığınız özellik veya testle alakası olmayan testler yürütme

Küçük projelerde, özellikle tek bir geliştiricisi olan projelerde, kod tabanınızın tüm test paketini düzenli olarak çalıştırma alışkanlığı geliştirmek istiyorsanız. Bu, özellikle testleriniz küçükse ve hızlı bir şekilde tamamlanıyorsa (en fazla birkaç saniyeden fazla yürütülür), böylece her şeyin nasıl sonuç vereceğini öğreteceğim.

Ön gönderim veya inceleme kapsamında testler yapın

Birçok proje, Virtual Verde için bir kod tabanının doğru kodu main dalında birleştirilir. Test konusunda yeniyseniz, daha önce açık kaynaklı projelere katkıda bulunmuş olsanız da, büyük ihtimalle çekme isteği (PR) sürecinin bir bölümü, projenin tüm testlerinin yani heyecan verici yeni katkınız, bahsi geçen nasıl oluşturulduğunu göstereceğim.

Testlerinizi yerel olarak çalıştırırsanız projenizin online deposu (örneğin, veya başka bir kod barındırma hizmeti) testlerinizin başarılı olup olmadığını Bu nedenle, bir ön gönderme görevi olarak testlerin çalıştırılması, her şey yolunda gitmesi anlamına gelir.

Örneğin GitHub, bunları "durum denetimleri" daha fazla bilgi edinin. GitHub İşlemler'e gidin. GitHub İşlemleri bir test yöntemidir: Her adım başarılı olmalıdır (başarısız olmamalı Error) emin olun. Eylemleri bir projeyle ilgili tüm halkla ilişkiler ve bir proje, siz koda katkıda bulunmadan önce Actions'ın geçmesini gerektirebilir. GitHub Varsayılan Node.js işlemi, adımlarından biri olarak npm test öğesini çalıştırır.

Bu test yaklaşımı, kod tabanınızın her zaman "yeşil" olduğundan emin olmaya çalışır kodunu kabul etmenizi öneririz.

Sürekli Entegrasyon kapsamında test çalıştırma

Yeşil PR'niz kabul edildikten sonra, çoğu kod tabanında tekrar projenizin main şubesine başvurur. Bu işlem, hemen ya da düzenli olarak (örneğin, saatlik veya her gece) yayınlayabilirsiniz. Bu sonuçları genellikle Sürekli Entegrasyon (CI) kontrol panelinin bir parçası olarak gösterilir: genel proje sağlığını gösterir.

Bu CI adımı, özellikle küçük kod tabanları olan projeler için gereksiz görünebilir. bu testler, inceleme sırasında geçildiğinden, bir değişiklik yapıldıktan sonra geçmelidir. Ancak, bu her zaman geçerli olmayabilir. Testleriniz başarılı olduktan sonra bile aniden başarısız olabilir üretiyoruz. Bunun nedenlerinden bazıları şunlardır:

• Bazen yarış koşulu olarak da bilinen birçok değişiklik, "tek seferde" kabul edildi. ve birbirlerini gizli ve test edilmemiş şekillerde etkilerler.
• Testleriniz tekrarlanabilir değil veya "kesintisiz" olarak test ediliyor ve hem web sitesi hem de ve kod değişiklikleri olmadan başarısız olur.
  • Kod tabanınızın dışındaki sistemlere bağlıysanız bu durum ortaya çıkabilir. Örneğin, proxy, Math.random() > 0.05 olduğunu varsayalım. Bu durumda rastgele %5 başarısız olur. .
• Bazı testler her halkla ilişkiler için çok maliyetli veya pahalıdır (ör. uçtan uca) testler (bununla ilgili daha fazla bilgiyi otomatik test türlerinde bulabilirsiniz), ve her zaman uyarıda bulunmadan zaman içinde bozulabilirler.

Bu sorunların üstesinden gelmek imkansız değildir, ancak bu durumun yazılım geliştirme, test ve yazılım geliştirme için tam tutarlılık sağlamayacaktır. bilim.

Geri çekilme ile ilgili ara

Sürekli entegrasyonun bir parçası olarak testler ve hatta testler çalıştırması durumunda derleme, zaman çizelgesinde "kırmızı" durumu veya testlerin başarısız olduğu anlamına gelen başka bir durum gösterilir. Daha önce belirtildiği gibi, Bu durum, testteki yarış koşulları da dahil olmak üzere çeşitli nedenlerden kaynaklanabilir. güvenilir olmayan testler olabilir.

Daha küçük projelerde ise bu içgüdüye göre işleri bir kriz olarak düşünebilirsiniz. Durdurun ihlal eden değişikliği geri çekin veya geri alın ve bilinen bir iyi bir durumda. Bu geçerli bir yaklaşım olabilir ancak şunu unutmayın: test (ve genel olarak yazılım!) bir hedef değil, sonucudur kendisi. Hedefiniz muhtemelen tüm testleri geçmek değil yazılım yazmaktır. Bunun yerine, zarar veren değişikliği başka bir değişiklik ile takip ederek ileri hatasını düzelten bir değişiklik yapın.

Öte yandan, geçmişte birçok farklı kurumda çalışan sürekli kırık bir durumda. Daha da kötüsü, büyük projede projenin alarm yorgunluğuna neden olacak kadar sık mola verme göz atabilirsiniz. Bu, liderlerin çözmesi gereken varoluşsal bir sorundur: Hatta "herkesin önündeki engelleri Geliştirme".

Bunun hızlı bir çözümü yoktur, ancak bu, yazmanın daha özgüvenli olmasına yardımcı olabilir ve testlerin kapsamını daraltmayı (basitleştirme) daha kolay bir şekilde belirlenebilir. Bileşen testinin sayısında artış veya entegrasyon testleri (Otomatik entegrasyon türleri hakkında daha fazla bilgi test etme), kullanıcıların güvenilirliğini zor olan ve yapmaya çalıştığı çok büyük bir uçtan uca testten her şeyi aynı anda yapabilirsiniz.

Kaynaklar

• Gecelik Derlemeler Yapmanın Avantajları

Öğrendiklerinizi sınayın