JavaScript test sistemi. JavaScript kodunun birim testi: stratejiler, kitaplıklar, araçlar

Kod testi, yazılım geliştirmenin ayrılmaz bir döngüsüdür. Yeni başlayan geliştirme ekipleri genellikle rolünü hafife alıyor ve uygulamanın işlevselliğini eski moda yöntemle kontrol ediyor - "çalışıyor, tamam." Er ya da geç bu strateji başarısız olur ve hata takip cihazı sayısız görev ordusu tarafından boğulmaya başlar. Böyle bir tuzağa düşmekten kaçınmak için, JavaScript kodunu test etmenin inceliklerini bir kez ve tamamen anlamanızı öneririm.

Günümüzde JavaScript, bir uygulamanın görünümünü güzelleştiren bir dilden çok daha fazlasıdır. JavaScript'in şaka yapmak veya menü oluşturmak için kullanıldığı dönemler geri dönülmez bir şekilde geride kaldı. Artık hem istemcide hem de sunucuda eşit derecede iyi çalışan bağımsız bir dildir. JavaScript'in rolü önemli ölçüde arttı; bu, kod yazarken diğer programlama dillerinde kendini kanıtlamış uygulamaları kullanmaktan çekinmemeniz gerektiği anlamına geliyor.

Uygulamalar ve paradigmalarla neyi kastediyorum? Tabii ki, MVC (model view denetleyicisi) mimari deseni ve kod organizasyon kalıpları. Bu basit hileleri takip ederek, hem bakımı kolay hem de otomatik olarak test edilebilecek daha iyi kodlar yazabileceksiniz.

En popüler test yönteminin her zaman sıradan bir göz testi olduğu bir sır değil. Özü utanç verici derecede basittir - birkaç bin satır kod yazarsınız, sorunu çözersiniz ve yaratımınızı başlatırsınız. Biraz oynadım, tıkladım, her şey çalışıyor gibi görünüyor, üretim sunucusuna yükleyebilirsiniz. Her şey son derece basittir ve geliştiricinin (ideal olarak "testçi" lakaplı bir kişi) gösterdiği dikkatle uygulamanın doğru çalıştığına güvenebilirsiniz.

Pratikte her şey biraz farklı oluyor. Kural olarak ayrı bir test uzmanı yoktur. Geliştiricinin kendisi, teknik özelliklerde belirtilen eylem sırasını gerçekleştirerek programın işlevselliğini kontrol etmeye çalışır. Daha gelişmiş kod dövmeleri, Selenyum gibi şeyleri kullanarak bu tür entegrasyon testlerini otomatikleştirir.

Böylece programcı yalnızca en ciddi hataları tespit etme fırsatını yakalar. Ne yazık ki, "aptalca" ve "istenmeyen" kullanıcı eylemlerinin yanı sıra iş mantığındaki kurnazca hareketler vakaların %99'unda perde arkasında kalıyor.

Testi yapan kişinin şahsında ayrı bir kişinin bulunması da sorunu kısmen ve belli bir süreye kadar çözmektedir. Kazıcısının detaylara olan ilgisini göz ardı etsek bile, uygulama büyüdükçe testlerinin kalitesi sıfıra düşecektir. Size pratikten bir örnek vereyim.

Bir gün küçük bir program geliştirmekle görevlendirildim. İşlevsellik açısından proje, mümkün olan en kısa sürede hayata geçirdiğim basit bir CRM'ye benziyordu. Hak ettiğim ücreti aldıktan sonra tüm kaynakları müşteriye teslim ettim ve sekiz ay boyunca projeyi unuttum. Sonra eğlence başladı. Müşteri programın işlevselliğini ciddi şekilde genişletmeye karar verdi ve yardım için beni aradı. Doğal olarak onu aldım ve işlev üstüne yeni işlev oluşturmaya başladım. İlk başta zor değildi, ancak işlevselliğin genel entegrasyonuna gelince, uğultulu bir böcek sürüsü bana doğru koştu. Kod parçaları çatışmaya başladı ve çatışmaları çözmek için çok zaman harcamak zorunda kaldık. “Peki, başvurunuzda sorun olduğunu nasıl fark etmediniz?” - dikkatli okuyucular soracaktır. Başlattım, ancak uygulamanın büyümesi nedeniyle, tüm işlevselliği toplu olarak test etmek için yeterli zamanım ve sinirlerim yoktu. Kendimi yalnızca bireysel işlevleri test etmekle sınırladım ve bunun için yüklü miktarda para ödedim. Hikayenin ana fikri şu: "Test etmeyi gelişimin ayrılmaz bir parçası olarak düşünün."

Birim testi, sinirlerinizi korumanın ve uygulamanın tek tek bölümlerinin performans garantilerini artırmanın en iyi yoludur. Bu korkunç kelimeye hiç rastlamadıysanız kısaca açıklayacağım. Birim testleri, test sürecini otomatikleştirmenize ve uygulamanızın her özelliğini test etmenize olanak tanır.

Yeni bir fonksiyonun geliştirilmesini tamamladıktan sonra (geliştirmeye başlamadan önce testler yazmak mümkündür), geliştirici, kodunu test etmek için özel bir kod yazar. Test kodunuzda farklı durumları simüle etmeniz ve değerleri döndürmeniz gerekir. Örneğin boşlukları kırpmak (trim) için bir fonksiyon yazdık. Performansını test etmek için aşağıdakileri belirtmemize olanak sağlayacak birkaç test hazırlamalıyız:

Ayrıca diğer giriş parametreleri için de testler ekleyebiliriz (örneğin, boşluk karakterini sekmeyle değiştirmek). Genel olarak, kodu ne kadar iyi testlerle kaplarsak ve olası olumsuz seçenekleri ne kadar iyi sağlarsak, en kritik anda kafada bir miktar saç kalma şansı da o kadar artar.

JS dünyasında testler genellikle özel çerçeveler kullanılarak yazılır. Testleri tanımlamak için ihtiyacınız olan her şeye ve en azından test ilerleme raporlarını sistematik hale getirmeye yönelik bazı araçlara sahiptirler.

Birim testini kullanmayan geliştiriciler, birim testinin ek kod yazmayı ve sürdürmeyi gerektirdiğini iddia etmeyi severler. Gerçek projelerde son teslim tarihlerinin çoğunlukla sıkı olduğunu ve ek kod yazmanın kesinlikle mümkün olmadığını söylüyorlar.

Son teslim tarihlerinin sıkı olduğu konusunda hemfikirim, ancak ekstra kod konusunda tartışmaya hazırım. Bir yandan, evet, testler ek kod gerektirir ve dolayısıyla bunu yazmak için zaman gerekir. Öte yandan bu kod, bir arabadaki hava yastığı rolünü oynuyor ve uygulama büyüdükçe mutlaka kendini amorti edecek.

Zamanınız olmadığında ve sınav yazmayı bırakma isteğiniz yüzünden eziyet çektiğinizde üç kez düşünün. Bu durumda, testi tamamen bırakmak yerine kodun yalnızca en zorlu bölümlerini testlerle kapsamak daha uygun olabilir. Her zaman geleceğe yönelik düşünün; sanki bir ay içinde programınız benzeri görülmemiş boyutlara ulaşabilecekmiş gibi.

Neden ana kodu yazmadan önce testi düşünmeniz gerektiğini söylüyorum? Evet, çünkü başlangıçta birim testlerin kapsaması gereken kod biraz farklı bir tarzda yazılmış. Her kod test edilemez. Mantık ve temsilleri karıştıran ve aynı zamanda düzgün bir şekilde test edilmesinin imkansız olduğu alanlara sıkıştırılmış kod. Burada her zaman birkaç basit kurala uymanızı tavsiye ederim:

QUnit özellikle JavaScript geliştiricileri arasında popülerdir. Birincisi, iyi belgelenmiştir ve kullanımı kolaydır, ikincisi ise jQuery'nin yazarları tarafından oluşturulmuştur. Kütüphane hem jQuery tabanlı hem de yerel JavaScript kodunu test etmek için uygundur.

QUnit'in en son sürümünü resmi web sitesinden indirebilirsiniz - http://qunitjs.com/. Kütüphane tek bir JS ve CSS dosyası olarak gelir. Diyelim ki gerekli bileşenleri yüklemeyi anladınız ve eğer öyleyse, bir deneme testi yazmanın zamanı geldi. Fazla uzağa gitmeyelim ve yukarıda bahsedilen trim() fonksiyonunu test etmeye çalışalım.

Testleri göstermek için aşağıdaki kurucuyla basit bir proje oluşturdum:

Index.html – test sonuçlarını görüntüleyecek ana dosya; - qunit-1.12.0.js – qunit kitaplık dosyası; - example.js – test için kod içeren dosya (bizim durumumuzda trim() fonksiyonunun açıklaması); - test.js – testleri içeren dosya; - qunit-1.12.0.css – testler içeren bir rapor tasarlama stilleri;

index.html ve test.js dosyalarının içeriği Liste 1 ve 2'de sunulmaktadır. En çok, test (trim()) altındaki işlevin bildirimini ve onu kontrol etmek için test kodunu içeren ikinci listeyle ilgileniyoruz. işlevsellik. Trim() fonksiyonunun herhangi bir yere yerleştirilebileceğini lütfen unutmayın; dergide yer kazanmak için onu ikinci listeye koydum.

Şimdi testlerin kendilerine bakalım. Kodumuzun işlevselliğini kontrol etmek için Qunit.js kütüphanesi bize çeşitli yöntemler sunar:

İkinci listede bu yöntemlerin pratikte nasıl uygulanacağını açıkça gösterdim. Test örneğini bu formda çalıştırırsanız tüm testler başarıyla geçecektir (ilgili şekle bakın). Başarılı olan ve başarısız olan testler arasındaki farkı görmek için bir testin kodunda biraz değişiklik yaptım. StrictEqual() kullanarak test çizgisine kasıtlı olarak hatalı bir sonuç ekledim (ilgili şekle bakın).

Basit fonksiyonları test etmeyi halletmiş gibiyiz. Her durumda, ekleyecek başka bir şeyim yok. Daha sonra gerçek kodu almanız ve testleri kendiniz yazmaya çalışmanız gerekir. JavaScript geliştiricileri için sıklıkla karşılaşılan başka bir göreve bakalım: eşzamansız işlevleri test etme. JavaScript koduyla doldurulmuş bir uygulama, Ajax kullanarak sunucu tarafıyla %99 oranında etkileşime girer. Bu kodu da işaretsiz bırakamazsınız, ancak test yazmak biraz farklı görünecektir. Bir örneğe bakalım:

AsyncTest("myAsyncFunc()", function() ( setTimeout(function() ( ok(myAsyncFunc() == true, "Veriler başarıyla aktarıldı"); start(); ), 500); ));

Bu örnek ile önceki örnek arasındaki temel fark, test() sarmalayıcısı yerine asyncTest() kullanılması, dolayısıyla doğrudan asenkron testle ilgilendiğimi belirtmesidir. Daha sonra bekleme süresini 500 ml'de başlatıyorum. sn. Bu süre zarfında myAsyncFunc() işlevi verileri test sunucusuna aktarmalı ve her şey yolundaysa true değerini döndürmelidir. En ilginç anın geldiği yer burasıdır. asyncTest() çağrıldığında yürütme iş parçacığı durur ve test tamamlandığında bağımsız olarak başlatılması gerekir. Yürütme akışını kontrol etmek için QUnit'in start() ve stop() yöntemleri vardır.

QUnit kütüphanesini kullanarak asenkron fonksiyonları test etmek oldukça basittir. Bakmak istediğim son örnek, birkaç eşzamansız kontrol gerçekleştiren bir test yazmayı içeriyor. Bu tür görevlerde ortaya çıkan ana soru, yürütme akışını başlatmak için en uygun yerdir. Resmi belge şunun gibi bir şey kullanmanızı önerir:

AsyncTest("myAsyncFunc()", function() ( wait(3); //Burada üç kontrol yapıyoruz tamam(myAsyncFunc(), "Dünyayı daha iyi bir yer haline getirmek 1"); ok(myAsyncFunc(), "Making the the world dünya daha iyi bir yer 2" ); ok(myAsyncFunc(), "Dünyayı daha iyi bir yer haline getirmek 3"); setTimeout(function() ( start(); ));

Pek çok arayüz öğesinin JavaScript'te yazıldığını her zaman hatırlamalısınız. Örneğin, bir kullanıcı bir pezevenge tıklar ve onun tıklamasına yanıt olarak bir şeyler olması gerekir. Projelerde bu tür “arayüz” kodlarından çok fazla var ve bunun da testlerle kapatılması gerekiyor. Bir kullanıcının tuş vuruşunu nasıl simüle edebileceğimizi ve bu eylem için ayrı bir test yazabileceğimizi görelim. Basılan tuşları kaydeden belirli bir fonksiyonumuzun olduğunu düşünelim. Üçüncü listede kodunu verdim:

Şimdi bu fonksiyonu test etmeye çalışalım. Öncelikle testin gövdesinde basılan tuşu taklit etmemiz gerekiyor. Bunu yapmanın en kolay yolu, birkaç satır kodla etkinlik oluşturmanıza olanak tanıyan jQuery kitaplığını kullanmaktır (bkz. Liste 4).

Test listesinin en başında, bir tuşa basmayı - "tuş aşağı" - taklit edecek bir etkinlik hazırlıyorum. Sekme tuşuna (kod 9) basmakla ilgileneceğiz. Ardından, tetikleyici() yöntemini kullanarak hazırlanan olayı gönderiyorum ve ardından teste başlayabilirim. İlk önce genel resmi kontrol ediyoruz - bir tuşa basılıp basılmadığını ve ardından kodunu kontrol ediyoruz.

Qunit.js kullanıcı eylemlerini test etmenize izin verdiğinden, DOM için testler yazmak da sorun olmayacaktır. Bu gerçekten doğrudur ve aşağıdaki örnek sözlerimi doğrulayacaktır. Bunun hakkında yorum yapmayacağım, sadece koda bakın ve her şey netleşecek:

Test("Yeni bir div öğesi ekleyin", function() ( var $fixture = $("#qunit-fixture"); $fixture.append("Bu yeni bir div"); equal($("div", $fixture) .length, 1, "Yeni div başarıyla eklendi!");

Qunit.js kütüphanesini kullanarak test yazmak kullanışlı ve basittir, ancak er ya da geç testin başlatılmasını ve sonuçların toplanmasını bir şekilde otomatikleştirme arzusuna sahip olacaksınız. Örneğin bu amaçla DigitalOcean'da yalnızca konsolu kullanarak yönetebildiğim ayrı bir sanal makinem var.

phantom.js projesi bu sorunu oldukça zarif bir şekilde çözüyor. Bu, Birim testleri yazmaya yönelik başka bir çerçeve değil, WebKit motorunun tam teşekküllü bir konsol sürümüdür. Basitçe söylemek gerekirse, bu uygulama bir tarayıcıyı taklit eder. phantom.js'nin yardımıyla, yalnızca test yürütmesinin doğrulanmasını otomatikleştirmek değil, aynı zamanda geliştiricinin önünde er ya da geç ortaya çıkan birçok sorunu da çözmek mümkündür: sayfa oluşturma sonuçlarının bir dosyaya (png, jpg) dönüştürülmesi, ağ izleme işlevleri (yükleme hızı, genel performans vb.), kullanıcı eylemlerinin emülasyonu vb. Zaman ayırıp bu projeyle ilgili resmi belgeleri okumanızı tavsiye ederim, kesinlikle kendiniz için ilginç bir şeyler bulacaksınız.

Phantom.js farklı platformlar (nix, mac OS X, windows) için derlenebilir. Her şeyi Windows'ta geliştirirseniz sorun olmaz - ikili dosyaları birleştirin ve devam edin. Yüklü iki video bağdaştırıcınız varsa, bunlardan biri NVidia'dır, başlatma sırasında küçük sorunlar ortaya çıkabilir. Bu durumda kenar çubuğunda açıklanan hack'i kullanmanız gerekecektir.

Phantom.js'yi pratikte tanımaya çalışalım. Son bölümde hazırlanan testleri phantom.js aracılığıyla çalıştırmak ve yürütme sonuçlarını konsola almak için özel bir yükleyici betiğine ihtiyacımız var - run-qunit.js. Konsolu açın (Windows üzerinde çalışıyorum, dolayısıyla cmd kullanıyorum) ve komutu şu biçimde yazın:

Phantom.exe

Benim durumumda başlatma komutu şöyle görünüyordu:

E:\soft\phantomjs>phantomjs.exe E:\temp\testjsforx\qunit\run-qunit.js file:///E: /temp/testjsforx/qunit/index.html Yürütülmesinin sonucu: Testler şu tarihte tamamlandı: 2592 milisaniye. 9 iddianın 9'u başarılı, 0'ı başarısız oldu.

Oluşturduğunuz uygulama hangi ölçekte olursa olsun mutlaka kodunuzu testlerle kaplamanız gerekiyor. En küçük programların bile desteklenmesi ve işlevsellik eklenmesi gereken hantal canavarlara dönüştüğünü bir kez daha hatırlatıyorum. İyi test edilmiş kod, başarının ve kalitenin anahtarıdır. Evet, otomatik testlere uygun kod yazmaya hemen başlamak kolay değil ama inanın bana, tüm bu eziyet gelecekte fazlasıyla karşılığını alacak. Bugünlük bu kadar, iyi şanslar!

Zamanınız yoksa basit işlevler için testler yazmanın bir anlamı yoktur (makaledeki örneklerdeki aynı trim() yöntemini kullanın), kodun en kritik bölümlerine odaklanmak daha iyidir. Sık değişen kod yazarken de aynı kurala uyulmalıdır. Canlı bir projenin teknik özellikleri sık sık değişir ve bazı fonksiyonların sürekli güncellenmesi gerekir. Bu tür değişiklikler hoş olmayan anlara yol açabilir - değiştirilen kod yeni verilerle iyi çalışır, ancak eski verileri organik olarak sindirmez. Dolayısıyla burada bir arıza yakalamamak adına bu tür fonksiyonların hemen testlerle kapsanması daha doğru olacaktır. Basit bir kuralı unutmayın - kodun tamamını testlerle ele alacak zaman yoktur, en önemli kısmını ele alın.

Öyle oldu, ancak bu makaledeki tüm örnekleri Linux'ta değil, eski güzel Windows 7'de test ettim. Phantom.js'nin birkaç video bağdaştırıcısı kullanan sistemlerde çalışırken küçük sorunlar yaşadığı ortaya çıktı. Dizüstü bilgisayarımda entegre video çipine ek olarak NVidia da var ve phantom.js nedeniyle phantom.exit() komutuna yanıt vermeyi kategorik olarak reddetti. Sonuç olarak script çalıştırıldıktan sonra phantom.js işlemi işini tamamlamadı ve bellekte takılmaya devam etti. Terminal penceresi ayrıca kapatma komutlarına yanıt vermeyi de durdurdu (ctrl + c yardımcı olmadı).

Benzer bir sorunla karşı karşıyaysanız ve phantom.js'yi Windows'ta kullanmayı planlıyorsanız, aşağıdaki hack'i yapmaya hazır olun. Nvidia Denetim Masasını açın. Ağaçta “3D Ayarları” öğesini bulun. Sağ tarafta “Tercih Edilen Grafik Bağdaştırıcısı” seçeneği görünmelidir. Varsayılan olarak değeri “Otomatik seçim” olarak ayarlanmıştır. Bunu “Yüksek performanslı Nvidia işlemcisi” veya “Tümleşik grafik donanımı” olarak değiştirmemiz gerekiyor. Bu basit numaranın ardından phantom.js itaatkar davranmaya başladı.

Şu konulara ilişkin bilgi testleri artık sitede mevcut: HTML, CSS, JavaScript, PHP, SQL.

Her test belirli bir konuyla ilgili 10 sorudan oluşur. Her soruda, bilgi seviyenizi mümkün olduğunca kapsamlı bir şekilde test etmek için belirli bir dilin en çeşitli uygulama alanlarına değinmeye çalıştım.

Elbette tüm testler ücretsizdir ve herkes bu sınavlara girebilir.

Test prosedürü:

Dikkat! Önceki soruya geri dönemezsiniz, bu yüzden cevaplamadan önce düşünün.

Uygulamanın bazı bölümlerinin davranışının çeşitli nedenlerle değişebileceği büyük projeler için etkili test senaryoları oluşturmak son derece önemli olabilir. Belki de en yaygın sorun, büyük bir geliştirici grubunun aynı veya ilgili modüller üzerinde çalışmasıdır. Bu, diğer programcılar tarafından yazılan işlevlerin davranışlarında planlanmamış değişikliklere yol açabilir. Veya sıkı teslim tarihleri ​​altında çalışmak, uygulamanın kritik kısımlarında kasıtsız değişikliklere yol açar.

Bir web uygulamasının test edilmesi genellikle sayfa öğelerinin görsel olarak değerlendirilmesini ve işlevselliğin işlevselliğinin ampirik olarak değerlendirilmesini içerir. Başka bir deyişle bölümler arasında hareket etme ve dinamik öğeler üzerinde eylemler gerçekleştirme.

Zamanla proje, işleyişini kontrol etme sürecini uzatan ve karmaşıklaştıran yeni işlevlerle dolar. Otomasyon için birim testi kullanılır.

Test senaryoları oluşturmaya yönelik 2 yaklaşım vardır:

• Whitebox Testing – test yazma, işlevselliğin uygulanmasına dayanır. Onlar. Sistem modüllerimizin çalışmasının dayandığı aynı algoritmaları kullanarak kontrol ediyoruz. Bu yaklaşım sistemin bir bütün olarak doğru çalışmasını garanti etmez.
• Blackbox Testi – komut dosyası oluşturma, sistem özelliklerine ve gereksinimlerine dayanır. Bu şekilde tüm uygulamanın sonuçlarının doğruluğunu kontrol edebilirsiniz ancak bu yaklaşım küçük ve nadir hataları yakalamanıza izin vermez.

Uyguladığınız her özelliği test etmeye değer gibi görünebilir. Bu tamamen doğru değil. Test yazmak geliştiricinin zamanını alır, bu nedenle bir uygulama oluşturma sürecini optimize etmek için yalnızca karmaşık, kritik işlevler veya diğer sistem modüllerinin sonuçlarına bağlı işlevler için testler hazırlamaya değer. Belirsiz mantığı, potansiyel olarak hatalara neden olabilecek testlerle örtün. Gelecekte optimize edilmesi planlanan kod bölümleri için testler oluşturmaya da değer; böylece optimizasyon sürecinden sonra bunların doğru şekilde yürütüldüğünü doğrulayabilirsiniz.

Genel olarak test maliyetlerini, geliştirme son tarihlerinin sıkılığına göre değerlendirmek son derece önemlidir. Elbette zamanınız sınırlı değilse her fonksiyonun testlerle ele alınmasına izin verebilirsiniz. Ancak kural olarak geliştirme, sıkı zaman baskısı altında gerçekleştirilir, dolayısıyla bir analistin veya deneyimli bir geliştiricinin görevi, testin nerede gerekli olduğunu anlamaktır. Ayrıca test yazmak projenin maliyetini arttırır.

Böylece birim testinin kullanımının haklı olduğu 3 durumu formüle edebiliriz:

1) Testler, hataların normalde aranmasına kıyasla daha hızlı tespit edilmesini mümkün kılıyorsa.

2) Hata ayıklama süresini azaltın

3) Sık sık değiştirilen kodu test etmenizi sağlar.

Ön ucun 3 ana bileşeninden (HTML, CSS, JavaScript) belki de yalnızca JavaScript kodunun test edilmesi gerekir. CSS, geliştiricinin/testçinin/müşterinin GUI'yi farklı tarayıcılarda görüntülediği, tamamen görsel olarak test edilir. HTML işaretlemesi aynı yöntem kullanılarak kontrol edilir.

Test senaryoları oluştururken aşağıdaki ilkelere göre yönlendirilmelisiniz:

• Testleriniz mümkün olduğunca basit olmalıdır.
• O zaman, uygulamanın sonuçlarının, tekrarlamaya çalıştığınız hatadan etkilenme olasılığı daha büyük olacaktır.
• Büyük birim testlerini ayrıştırın.
• Hatanın spesifik konumunu bulmak daha iyidir.
• Testleri bağımsız yapın.

Js kodunun birim testi için çeşitli kütüphaneler vardır. Belki de en yaygın olanı QUnit'tir. Bu kitaplığı kullanarak birim testleri gerçekleştirmek için, test kitaplığının, test edilmesi gereken kodun ve testlerin kendilerinin bağlanacağı basit bir html sayfası olan bir "sanal alan" oluşturmamız gerekecek.

Testler için işlevler:

(function() ( window.stepen = function(int) ( var result = 2; for (var i = 1; i< int; i ++) { result = result * 2; } return result; } window.returnFunc = function() { return "ok"; } })();

Test listesi:

Test("stepen()", function() ( equal(stepen(2), 4, "2^2 - eşit yöntem"); ok(stepen(3) === 8, "2^3 - tamam yöntem" ); deepEqual(stepen(5), 32, "2^5 - deepEqual yöntemi"); asyncTest("returnFunc()", function() ( setTimeout(function() ( equal(returnFunc(), "ok", "Async Func Test"); start(); ), 1000); ));

Gördüğünüz gibi QUnit, kod yürütme sonuçlarını beklenen sonuçlarla karşılaştırmak için 3 işlevi destekler:

• ok() – döndürülen sonuç = doğruysa testin başarılı olduğunu kabul eder
• equal() – sonucu beklenen sonuçla karşılaştırır
• deepEqual() – sonucu beklenen sonuçla karşılaştırır ve türünü kontrol eder

Yürütme sonucu:

Gördüğünüz gibi QUnit kütüphanesi aynı anda birden fazla tarayıcının kodunu test ediyor.

Bir dizi başka birim test kütüphanesi mevcuttur. Ancak içlerinde test senaryoları oluşturma konsepti aynıdır, yani birini anladıktan sonra diğerine geçmeniz zor olmayacaktır.

Modern js kodunun bir özelliği, eşzamansız yürütülmesidir. Test kütüphaneleri genellikle eşzamansız testler yürütme yeteneğine sahiptir. Ancak örneğin, arka uca bir alma isteği gönderen ve bundan bir yanıt döndüren bir işlevi test etmeye çalışıyorsanız, testleri yürütmek için iş parçacığını stop() işleviyle durdurmanız, işlemi başlatmanız gerekir. test altındaki işlevi kullanın ve ardından iş parçacığını start() yöntemiyle yeniden başlatın ve setTimeout() işlevine "sarın". Onlar. işlevin yürütmeyi tamamlayacağı belirli bir süre ayarlamanız gerekir. Bu segmentin süresini dikkatlice seçmeniz gerekiyor. Bir yandan, bir yöntemin uzun süre çalışması, uygulamanın işlevselliğinin belirli bir uygulaması için bir özellik, hatta bir zorunluluk veya yanlış davranış olabilir.

Backbone.js kullanılarak yazılan uygulamaları test etme örneği için, içinde açıklanan projeyi kullanacağız.

Aşağıdakileri kontrol etmek için birim testlerini kullanabilirsiniz:

• Modellerin ve denetleyicilerin doğru oluşturulması
• Modellerdeki verilerin doğruluğu
• Denetleyici yöntemlerinin yürütülmesi (bunun için bir sonuç döndürmeleri gerekir)
• Görüntüleme yükleme başarısı

Test kodu:

Test("Backbone.js", function() ( ok(sample, "Ad alanı kontrolü"); ok(sample.routers.app, "Yönlendirici kontrolü"); ok(sample.core.pageManager.open("chat") , "Sayfa açma testi (Denetleyici yöntemi çağrısı)") ok(sample.core.state, "Model kontrolü"); equal(sample.core.state.get("content")), "sintel", "Model verileri test alma " "); stop(); tamam(function() ( $.ajax(( url: "app/templates/about.tpl", dataType: "text")).done(function(data) ( self.$el .html(veri); dönüş verileri; ))), "Şablon yükleme kontrolü" (start();), 1000);

Test hatalarıyla çalışmanın sonucu:

Tipik olarak bir uygulamayı dağıtmak, yoğun geliştirme sırasında oldukça sık gerçekleştirilmesi gereken bir görevdir. Bu nedenle bu işlem genellikle otomatiktir. Çalışmamızda sürekli entegrasyona yönelik bir araç olan Jenkins'i kullanıyoruz. Buradaki fikir, Jenkins aracılığıyla dağıtımı otomatik testlerle birleştirmektir.

QUnit testleri tarayıcıda çalışır. Bir tarayıcının çalışmasını taklit eden yazılım olan Phantomjs, bu özelliği aşmamıza yardımcı olacaktır. phantomjs geliştiricileri QUnit testlerini yürütmek için zaten bir komut dosyası sağladılar, ancak doğru çalışması için biraz değiştirilmesi gerekiyordu.

/** * Test koşulu doğru olana veya zaman aşımı oluşana kadar bekleyin.< Default Max Timout is 3s start = new Date().getTime(), condition = false, interval = setInterval(function() { if ((new Date().getTime() - start < maxtimeOutMillis) && !condition) { // If not time-out yet and condition not yet fulfilled condition = (typeof(testFx) === "string" ? eval(testFx) : testFx()); //< defensive code } else { if(!condition) { // If condition still not fulfilled // (timeout but condition is "false") console.log(""waitFor()" timeout"); phantom.exit(1); } else { // Condition fulfilled (timeout and/or condition is //"true") console.log(""waitFor()" finished in " + (new Date().getTime() - start) + "ms."); typeof(onReady) === "string" ? eval(onReady) : onReady(); //< Do what it"s supposed to do once the // condition is fulfilled clearInterval(interval); //< Stop this interval } } }, 100); // repeat check every 250ms }; }; if (phantom.args.length === 0 || phantom.args.length >2) console.log("Kullanım: run-qunit.js URL'si");

phantom.exit(); ) var sayfa = yeni Web Sayfası(); // "console.log()" çağrılarını Sayfa // bağlamından ana Phantom bağlamına (yani mevcut "bu") yönlendirin page.onConsoleMessage = function(msg) ( console.log(msg); ); page.open(phantom.args, function(status)( if (status !== "başarılı") ( console.log("Ağa erişilemiyor"); phantom.exit(); ) else ( waitFor(function()) ( return page.evaluate(function())( var el = document.getElementById("qunit-testresult"); if (el && el.innerText.match("tamamlandı")) ( return true; ) return false; )) ; ), function())( var başarısızNum = page.evaluate(function())( var el = document.getElementById("qunit-testresult"); console.log(el.innerText); try ( return document.getElementsByClassName( "fail" ).innerHTML.length; ) catch (e) ( return 0; ) return phantom.exit((parseInt(failedNum, 10) ? 1: ));

Sonuçlarla ilgili mesajların konsola çıktısını almak için test komut dosyasına bir günlük kaydı işlevi eklemeniz gerekir.

Node.js'de basit bir hesap makinesi uygulaması örneğini kullanma. Mocha çerçevesini kullanarak test edeceğiz.

• Uygulamamızın yapabilecekleri:
• Herhangi iki sayıyı toplayın, çıkarın, bölün ve çarpın;
• Sayı dışında bir şey girilirse bir uyarı gösterin ve çıkın;

Son kullanıcının uygulamayı kullanabilmesi için bir komut satırı arayüzünün de olması gerekir.

• İhtiyacımız olan şey:
• Node.js ve npm;

JavaScript bilgisi: kod sözdizimi ve yapısı, veri türleri, matematiksel işlemler ve koşullu ifadeler.

Çevreyi ayarlama

Node.js kullandığımız için dosyalar ve bağımlılıklar için yerel bir ortam oluşturmamız gerekiyor. Yeni bir klasör oluştur hesap . Komut satırında bu dizine gidin ve npm init komutuyla yeni bir dosya oluşturacak yeni bir proje oluşturun. paket.json

programımız için. Paket adını, sürümünü, açıklamasını ve paketle ilgili diğer bilgileri girmeniz istenecektir. Bir isim girebilirsiniz calc.js basmaya devam et Girmek

test komutu: mocha . Komut satırında bu dizine gidin ve npm init komutuyla yeni bir dosya oluşturacak yeni bir proje oluşturun. Tüm bilgileri girdikten sonra script bir dosya oluşturacaktır.

( "name": "calc.js", "version": "1.0.0", "description": "Node.js'de basit hesap makinesi", "main": "index.js", "scripts": ( " test": "mocha"), "yazar": "", "lisans": "ISC")

Bu aşamadaki son adım Mocha'yı kurmaktır. Yüklemek için aşağıdaki komutu girin:

Npm kurulumu --save-dev mocha

Bu komutu kullandıktan sonra klasör görünecektir node_modules, dosya package-lock.json ve dosyada . Komut satırında bu dizine gidin ve npm init komutuyla yeni bir dosya oluşturacak yeni bir proje oluşturun. aşağıdaki satırlar görünecektir:

"devDependegency": ("mocha": "^4.0.1")

Dosya oluştur test.js. Node.js'nin yerleşik modülünü kullanacağız ileri sürmek doğru ve doğrunun doğru olup olmadığını kontrol etmek için. Bu doğru olduğuna göre testin geçmesi gerekir:

Const iddia = require("iddia"); it("true döndürmeli", () => ( iddia.equal(true, true); ));

Şimdi testi komut satırından çalıştırın:

$ npm testi > mocha ✓ doğru 1 geçişi döndürmelidir (8ms)

Test beklendiği gibi gitti, dolayısıyla ortamı ayarlamayı bitirdik. Şuradan kaldır: test.js const const = require("assert"); satırı dışındaki her şey .

Dosyayı kullanacağız test.js tüm uygulama oluşturma süreci boyunca. İki dosya daha oluşturun: işlemler.js aritmetik ve doğrulama işlevleri için ve Paket adını, sürümünü, açıklamasını ve paketle ilgili diğer bilgileri girmeniz istenecektir. Bir isim girebilirsiniz uygulamanın kendisi için. Çok uzun ve karmaşık hale gelmesinler diye çok fazla dosya kullanıyoruz. İşte güncel dosya listemiz:

• Paket adını, sürümünü, açıklamasını ve paketle ilgili diğer bilgileri girmeniz istenecektir. Bir isim girebilirsiniz;
• node_modules;
• işlemler.js;
• package-lock.json;
• . Komut satırında bu dizine gidin ve npm init komutuyla yeni bir dosya oluşturacak yeni bir proje oluşturun.;
• test.js;

Uygulamamız için ilk gerçek testi ekleyelim.

Öncelikle uygulamamızın herhangi iki sayıyı toplama, çıkarma, bölme ve çarpma işlemlerini yapabilmesi gerekiyor. Bu, bu işlemlerin her biri için ayrı bir fonksiyon oluşturmamız gerektiği anlamına gelir.

Eklemeyle başlayalım. İki sayının beklenen toplamının kesin olarak elde edileceği bir test yazacağız. Aşağıdaki kodda, add() işlevi 4'ü kullanarak 1 ve 3'ün toplamının eşit olup olmadığını kontrol ediyoruz:

Const iddia = require("iddia"); it("1 ve 3'ün toplamını doğru buluyor", () => ( iddia.equal(add(1, 3), 4); ));

Testi npm test komutunu kullanarak çalıştırdıktan sonra aşağıdakileri görüyoruz:

> mocha 0 geçiyor (9ms) 1 başarısız 1) 1 ve 3'ün toplamını doğru buluyor: ReferenceError: add is not define at Context.it (test.js:5:16) npm ERR! Test başarısız oldu. Daha fazla ayrıntı için yukarıya bakın.

Test, ReferenceError: add is not defines mesajıyla başarısız oldu. Henüz mevcut olmayan add() fonksiyonunu test ediyoruz, dolayısıyla bu sonuç oldukça beklenen bir sonuçtur.

Dosyada add() fonksiyonunu oluşturalım işlemler.js:

Sabit toplama = (x, y) => (+x) + (+y);

Bu işlev iki bağımsız değişken x ve y'yi alır ve bunların toplamını döndürür. x + y yerine (+x) + (+y) yazdığımızı fark etmişsinizdir. Girişin bir dize olması durumunda argümanı bir sayıya dönüştürmek için tekli operatörü kullanırız.

Not Bu, ES6'ya eklenen ok işlevini ve örtülü dönüşü kullanır.

Node.js kullandığımız ve kodu birden fazla dosyaya böldüğümüz için, kodu dışa aktarmak için module.exports kullanmamız gerekiyor:

Sabit toplama = (x, y) => (+x) + (+y); module.exports = (ekle)

Dosyanın başında test.js kodu şuradan içe aktarıyoruz: işlemler.js require() kullanarak. Fonksiyonu işlemler değişkeni aracılığıyla kullandığımızdan, add() işlevini operasyonlar.add() olarak değiştirmemiz gerekir:

Const işlemleri = require("./operations.js"); const iddia = require("iddia"); it("1 ve 3'ün toplamını doğru buluyor", () => ( iddia.equal(operations.add(1, 3), 4); ));

Testi çalıştıralım:

$ npm test > mocha ✓ 1 ve 3'ün toplamını doğru şekilde bulur 1 geçen (8ms)

Artık çalışan bir fonksiyonumuz var ve testler geçiyor. Diğer işlem işlevleri benzer şekilde çalıştığından, subtract() , multiple() vedivide() için testler eklemek kolaydır:

It("1 ve 3'ün toplamını doğru buluyor", () => ( iddia.equal(operations.add(1, 3), 4); )); it("-1 ile -1'in toplamını doğru buluyor", () => (statement.equal(operations.add(-1, -1), -2); )); it("33 ile 3 arasındaki farkı doğru buluyor", () => ( iddia.equal(operations.subtract(33, 3), 30); )); it("12 ile 12'nin çarpımını doğru buluyor", () => ( iddia.equal(operations.multiply(12, 12), 144); )); it("10 ile 2'nin bölümünü doğru buluyor", () => ( iddia.equal(operations.divide(10, 2), 5); ));

Şimdi tüm işlevleri oluşturup dışa aktaralım test.js:

Sabit toplama = (x, y) => (+x) + (+y); const çıkarma = (x, y) => (+x) - (+y); sabit çarpım = (x, y) => (+x) * (+y); sabit böl = (x, y) => (+x) / (+y); module.exports = ( toplama, çıkarma, çarpma, bölme, )

Ve yeni testler yapalım:

$ npm test > mocha ✓ 1 ve 3'ün toplamını doğru bulur ✓ -1 ve -1'in toplamını doğru bulur ✓ 33 ve 3'ün farkını doğru bulur ✓ 12 ve 12'nin çarpımını doğru bulur ✓ 10 bölümünü doğru bulur ve 2 5 geçme (8 ms)

Tüm testler başarıyla geçtiğinden artık uygulamamızın ana fonksiyonlarının doğru çalışacağından emin olabiliriz. Artık bazı ek doğrulamalar yapabilirsiniz.

Şimdilik kullanıcı bir sayı girip istenen işlemi seçtiğinde her şey yolunda gidiyor. Ancak bir sayı ile bir dizenin toplamını bulmaya çalışırsanız ne olur? Uygulama işlemi gerçekleştirmeye çalışacak ancak bir sayı beklediği için NaN döndürecektir.

Tuhaf bir değer döndürmek yerine, ikinci görevi yapmanın zamanı geldi; uygulamanın bir uyarı göstermesini sağlayın ve girilen argüman bir sayı değilse çıkın.

Öncelikle girişin sayı olup olmadığını kontrol edecek bir fonksiyon yazmanız gerekiyor. Uygulama yalnızca sayılarla çalışmalıdır, bu nedenle üç durumu ele alacağız:

validateNumbers() işlevi her iki parametreyi de kontrol edecektir. isNaN() işlevi, parametrenin bir sayı olup olmadığını kontrol eder ve değilse false değerini döndürür. Aksi takdirde, doğrulamanın başarılı olduğunu belirten true değerini döndürür.

Const validateNumbers = (x, y) => ( if (isNaN(x) && isNaN(y)) ( return false; ) return true; )

Dosyanın sonunda module.exports dosyasına validateNumbers eklemeyi unutmayın. Artık yeni testler yapabilirsiniz:

$ npm test 1) sayı yerine bir dize kullanıldığında bir hata bildirir ✓ bir sayı yerine iki dize kullanıldığında bir hata bildirir ✓ iki sayı kullanıldığında başarılı 7 geçme (12ms) 1 başarısız 1) bir dize kullanırken bir hata bildirir sayı yerine: AssertionError : true == false + beklenen - gerçek -true +false

İki test geçti ancak biri başarısız oldu. İki sayıya yönelik test, iki diziye yönelik testte olduğu gibi başarıyla geçti. Dize ve sayı girişini kontrol etmek için aynı şey söylenemez.

Fonksiyonumuza tekrar bakarsanız şunu fark edeceksiniz: ikisi birden Fonksiyonun false değerini döndürmesi için parametrelerin NaN olması gerekir. Parametrelerden en az biri NaN olduğunda aynı etkiyi elde etmek istiyorsak && yerine || koymamız gerekir. :

Const validateNumbers = (x, y) => ( if (isNaN(x) || isNaN(y)) ( return false; ) return true; )

Bu değişikliklerden sonra npm testini tekrar çalıştırırsanız tüm testler başarıyla geçecektir:

✓ sayı yerine dize kullanıldığında hata bildirir ✓ sayı yerine iki dize kullanıldığında hata bildirir ✓ iki sayı kullanıldığında başarılı 8 geçiş (9ms)

Uygulamamızın tüm işlevlerini test ettik. İşlevler matematik işlemlerini başarıyla gerçekleştirir ve girişi doğrular. Son aşama kullanıcı arayüzünün oluşturulmasıdır.

Zaten gerekli işlevlere sahibiz, ancak kullanıcı henüz bunları kullanamıyor. Bu nedenle bir arayüze ihtiyacımız var. Uygulamamız için bir komut satırı arayüzü oluşturacağız.

Şu anda dosya Paket adını, sürümünü, açıklamasını ve paketle ilgili diğer bilgileri girmeniz istenecektir. Bir isim girebilirsiniz boş olmalıdır. Uygulamamızın saklanacağı yer burasıdır. İlk önce işlevleri içe aktarmanız gerekir. işlemler.js:

Const işlemleri = require("./operations.js");

Arayüzün kendisi Node.js'de yerleşik olan Readline CLI modülünü kullanacaktır:

Const okuma satırı = require("readline");

İhtiyacınız olan her şeyi içe aktardıktan sonra uygulamanızı oluşturmaya başlayabilirsiniz. Arayüzü oluşturmak için rl değişkeni aracılığıyla erişilebilen readline'ı kullanacağız:

Const rl = readline.createInterface(( girdi: süreç.stdin, çıktı: süreç.stdout ));

Kullanıcının programı başlattıktan sonra görmesi gereken ilk şey bir karşılama mesajı ve kullanım talimatlarıdır. Bunu yapmak için console.log() kullanacağız:

Console.log(` Calc.js Node.js'de bir hesap makinesi açtınız! Versiyon: 1.0.0. Kullanım: Kullanıcı iki sayı girmeli ve sonra onlarla ne yapacağını seçmelidir. `);

Hesap makinesinin işlevlerine girmeden önce, console.log() işlevinin beklendiği gibi çalışıp çalışmadığını kontrol edelim. Programın bir mesaj yazdırıp çıkmasını sağlayacağız. Bunu yapmak için sonuna rl.close() yöntemine bir çağrı ekleyin.

Uygulamayı çalıştırmak için düğüm ve dosya adını girin:

$ node calc.js Calc.js Node.js hesap makinesini açtınız! Sürüm: 1.0.0. Kullanım: Kullanıcı iki sayı girmeli ve ardından onlarla ne yapacağını seçmelidir.

Program bir karşılama mesajı görüntüler ve çıkar. Şimdi kullanıcı girişi eklememiz gerekiyor. Kullanıcının aşağıdakileri yapması gerekir: iki sayı ve bir işlem seçin. Her giriş rl.question() yöntemi tarafından istenecektir:

Rl.question("İlk sayıyı girin: ", (x) => ( rl.question("İkinci sayıyı girin: ", (y) => ( rl.question(` Aşağıdaki işlemlerden birini seçin: Toplama ( +) Çıkarma (-) Çarpma (*) Bölme (/) Seçiminiz: `, (seçim) => ( // kod rl.close(); ));

X değişkenine ilk numara, y ikinci numaraya atanır ve seçilen işlem seçilir. Artık programımız girdi istiyor ancak aldığı verilerle hiçbir şey yapmıyor.

Üçüncü girişten sonra yalnızca sayıların girildiğini kontrol etmeniz gerekir. Bunu yapmak için validateNumbers() fonksiyonunu kullanacağız. NOT operatörünü kullanarak sayıların girilip girilmediğini kontrol edeceğiz ve girilmemişse programı sonlandıracağız:

If (!operations.validateNumbers(x, y)) ( console.log("Yalnızca sayı girilebilir! Lütfen programı yeniden başlatın."); )

Her şey doğru girilirse, daha önce oluşturulan işleme karşılık gelen yöntemi çalıştırmanız gerekir. Dört olası seçeneği işlemek için bir switch ifadesi kullanacağız ve işlemin sonucunu yazdıracağız. Var olmayan bir işlem seçildiyse, kullanıcıya tekrar denemesini söyleyen varsayılan bir blok yürütülecektir:

If (!operations.validateNumbers(x, y)) ( console.log("Yalnızca sayılar girilebilir! Lütfen programı yeniden başlatın."); ) else ( switch (seçim) ( case "1": console.log(` $(x) ve $(y) toplamı eşittir $(operations.add(x, y)).`); break; case "2": console.log(`$(x) ve $( arasındaki fark) y) $(operations.subtract(x, y)).`); break; case "3": console.log(`$(x) ile $(y)'nin çarpımı: $(operations.multiply(x) , y))).`) ; break; case "4": console.log(`$(x) ve $(y)'nin bölümü: $(operations.divide(x, y)).'); programı yeniden başlatın ve 1'den 4'e kadar bir sayı seçin."); break; ))

Not Buradaki console.log() işlevleri, ifadelere izin veren şablon dizelerini kullanır.

/** * Node.js'de yerleşik Readline komut satırı arayüzünü kullanan hesap makinesi uygulamasını kullanan basit bir hesap makinesi.

*/ const işlemler = require("./operations.js"); const readline = require("readline"); // Arayüzü oluşturmak için readline'ı kullanın const rl = readline.createInterface(( input: proses.stdin, çıktı: proses.stdout )); console.log(` Calc.js Node.js'de bir hesap makinesi açtınız! Sürüm: 1.0.0. Kullanım: Kullanıcı iki sayı girmeli ve sonra onlarla ne yapacağını seçmelidir. `); rl.question("İlk sayıyı girin: ", (x) => ( rl.question("İkinci sayıyı girin: ", (y) => ( rl.question(` Aşağıdaki işlemlerden birini seçin: Toplama ( +) Çıkarma (-) Çarpma (*) Bölme (/) Seçiminiz: `, (seçim) => ( if (!operations.validateNumbers(x, y)) ( console.log("Sadece sayı girilebilir! Lütfen) programı yeniden başlatın. "); ) else ( switch (seçim) ( case "1": console.log(`$(x) ve $(y)'nin toplamı $(operations.add(x, y))'dir. `); break; case "2": console.log(`$(x) ile $(y) arasındaki fark $(operations.subtract(x, y)).`); break; console.log(`$( x) ile $(y)'nin çarpımı şuna eşittir: $(operations.multiply(x, y))).'); break; $(x) ve $(y) eşittir $(operations.divide(x, y)).`); break; default: console.log("Lütfen programı yeniden başlatın ve 1'den 4'e kadar bir sayı seçin." ) kırmak; ; ));

Artık uygulamamız hazır. Son kez çalışmasını kontrol edelim. 999 ve 1'i girin ve çıkarma işlemini seçin:

$ node calc.js Birinci sayıyı girin: 999 İkinci sayıyı girin: 1 Seçiminiz: 2 999 ile 1 arasındaki fark 998.