Birim testi nedir? [kapalı]

Belirli bir dilde 'nasıl' test yapılacağını soran birçok soru gördüm, ancak 'ne', 'neden' ve 'ne zaman' diye soru sormuyorum.

• Bu ne?
• Benim için ne yapar?
• Neden kullanmalıyım?
• Ne zaman kullanmalıyım (değilken de)?
• Bazı yaygın tuzaklar ve yanlış anlamalar nelerdir?

Birim testi, kabaca söylemek gerekirse, kodunuzun bitlerini test koduyla izole olarak test etmektir. Akla gelen acil avantajlar:

• Testlerin yapılması otomatikleştirilebilir ve tekrarlanabilir hale gelir
• Bir GUI aracılığıyla nokta ve tıklama testinden çok daha ayrıntılı bir düzeyde test edebilirsiniz

Test kodunuz bir dosyaya yazarsa, bir veritabanı bağlantısı açarsa veya ağ üzerinden bir şey yaparsa, bu kodun bir entegrasyon testi olarak daha uygun bir şekilde sınıflandırıldığını unutmayın. Entegrasyon testleri iyi bir şeydir, ancak birim testlerle karıştırılmamalıdır. Ünite test kodu kısa, tatlı ve hızlı bir şekilde uygulanmalıdır.

Birim testine bakmanın bir başka yolu da önce testleri yazmanızdır. Bu Teste Dayalı Geliştirme (kısaca TDD) olarak bilinir. TDD ek avantajlar sağlar:

• Spekülatif "Gelecekte buna ihtiyacım olabilir" kodunu yazmıyorsunuz - sadece testleri geçmek için yeterli
• Yazdığınız kod her zaman testlerin kapsamındadır
• Önce testi yazarak, kodu uzun vadede genellikle tasarımını geliştiren kodu nasıl aramak istediğinizi düşünmeye zorlanırsınız.

Şimdi birim testi yapmıyorsanız, denemenizi öneririz. İyi bir kitap alın, pratik olarak herhangi bir xUnit-kitap yapacak, çünkü kavramlar aralarında çok transfer edilebilir.

Bazen yazı birimi testleri acı verici olabilir. Bu şekilde ulaştığında, size yardım edecek birini bulmaya çalışın ve "sadece lanet kodunu yazmak" konusundaki cazibeye direnin. Birim testi, bulaşıkları yıkamak gibidir. Her zaman hoş değil, ama mecazi mutfağınızı temiz tutar ve gerçekten temiz olmasını istersiniz. :)

Düzenleme: Bu kadar yaygın olup olmadığından emin olmasam da, bir yanlış anlama akla geliyor. Bir proje yöneticisinin birim testlerinin takıma tüm kodu iki kez yazdığını söylediğini duydum. Eğer öyle görünüyor ve hissediyorsa, yanlış yapıyorsun. Testlerin yazılması genellikle gelişimi hızlandırmakla kalmaz, aynı zamanda size başka türlü sahip olmayacağınız uygun bir "şimdi bitti" göstergesi de verir.

Dan'a katılmıyorum (daha iyi bir seçim sadece cevap vermeyebilir) ... ...

Birim testi, sisteminizin davranışını ve işlevselliğini test etmek için kod yazma işlemidir.

Testlerin kodunuzun kalitesini artırdığı açıktır, ancak bu birim testin yüzeysel bir yararıdır. Gerçek faydalar:

1. Davranışı değiştirmediğinizden (yeniden düzenleme) emin olurken teknik uygulamayı değiştirmeyi kolaylaştırın. Uygun şekilde test edilmiş kod, fark edilmeden hiçbir şeyi kırma şansı olmadan agresif bir şekilde yeniden düzenlenebilir / temizlenebilir.
2. Davranış eklerken veya düzeltme yaparken geliştiricilere güven verin.
3. Kodunuzu belgeleyin
4. Kodunuzun sıkı bir şekilde bağlı olduğu alanları belirtin. Birbirine sıkı sıkıya bağlı test kodu üniteyi bulmak zor
5. API'nızı kullanmanın bir yolunu sağlayın ve zorlukları erkenden araştırın
6. Çok uyumlu olmayan yöntemleri ve sınıfları gösterir

Ünitenizi test etmelisiniz çünkü müşterinize bakım yapılabilir ve kaliteli bir ürün sunmak sizin yararınıza olacaktır.

Gerçek dünya davranışını modelleyen herhangi bir sistem veya sistemin bir parçası için kullanmanızı öneririm. Başka bir deyişle, özellikle kurumsal gelişim için çok uygundur. Ben atma / yarar programları için kullanmazdım. Bir sistemin test etmek için sorunlu kısımları için kullanmam (UI yaygın bir örnektir, ancak bu her zaman böyle değildir)

En büyük tuzak, geliştiricilerin çok büyük bir birimi test etmeleri veya bir yöntemi bir birim olarak görmeleri. Bu özellikle, Ters Çevirme Kontrolü'nü anlamadığınızda geçerlidir - bu durumda birim testleriniz her zaman uçtan uca entegrasyon testine dönüşür. Birim testi, bireysel davranışları test etmelidir - ve çoğu yöntemin birçok davranışı vardır.

En büyük yanılgı, programcıların test etmemesi gerektiğidir. Sadece kötü veya tembel programcılar buna inanıyor. Çatınızı inşa eden adam test etmemeli mi? Kalp kapağını değiştiren doktor yeni kapağı test etmemeli mi? Yalnızca bir programcı kodunun yapmasını istediği şeyi yaptığını test edebilir (KG, uç durumları test edebilir - kod, programcının istemediği şeyleri yapması söylendiğinde nasıl davranır ve istemci kabul testi yapabilir - kod yapar mı? müşterinin yapması için ne ödediğini)

"Yeni bir projenin açılması ve bu özel kodun test edilmesi" yerine birim testin temel farkı, otomasyonun otomatik ve dolayısıyla tekrarlanabilir olmasıdır .

Kodunuzu manuel olarak test ederseniz, kodun mevcut durumda mükemmel şekilde çalıştığına sizi ikna edebilir . Ama bir hafta sonra, içinde küçük bir değişiklik yaptığınızda ne olacak? Eğer zaman elle tekrar tekrar test etmek istekli misiniz şey kodunuzda değiştirir? Büyük olasılıkla değil :-(

Eğer Ama eğer birkaç saniye içinde tek bir tıklama, aynı şekilde, birlikte, testlerin her zaman çalıştırmak , o zaman onlar olacak bir şey bozuldu zaman hemen size gösterir. Ayrıca, birim testlerini otomatik derleme işleminize entegre ederseniz, tamamen alakasız görünen bir kod kod tabanının uzak bir bölümünde bir şey kırdığı durumlarda bile hatalar konusunda sizi uyaracaklardır - hatta sizin için bile olmayacağı zaman söz konusu işlevselliği yeniden test etme ihtiyacı.

Bu, el testlerine göre birim testlerinin ana avantajıdır. Ama bekleyin, dahası var:

• birim testleri geliştirme geri besleme döngüsünü önemli ölçüde kısaltır : ayrı bir test departmanı ile kodunuzda bir hata olduğunu bilmeniz haftalarca sürebilir, bu süre zarfında bağlamın çoğunu zaten unuttunuz, bu nedenle saatlerce sürebilir hatayı bulup düzeltin; Birim testleri ile OTOH, geribildirim döngüsü saniye cinsinden ölçülür ve hata düzeltme işlemi tipik olarak "oh sh * t, bu durumu burada kontrol etmeyi unuttum" çizgileri boyunca :-)
• birim testleri kodunuzun davranışını etkili bir şekilde belgelendirir (anlarsınız)
• birim testi sizi tasarım seçimlerinizi yeniden değerlendirmeye zorlar, bu da daha basit ve temiz bir tasarım sağlar

Birim test çerçeveleri de testlerinizi yazmanızı ve çalıştırmanızı kolaylaştırır.

Bana üniversitede ünite sınavı öğretmedim ve "almam" biraz zaman aldı. Ben okudum, "ah, doğru, otomatik test, bu güzel olabilir sanırım" gitti ve sonra unuttum.

Bu konuyu gerçekten anlayabilmem biraz uzun sürdü: Diyelim ki büyük bir sistem üzerinde çalışıyorsunuz ve küçük bir modül yazıyorsunuz. Derler, adımlarına koyarsınız, harika çalışır, bir sonraki göreve geçersiniz. Dokuz ay boyunca ve iki sürüm sonra bir başkası programın ilgisiz görünen bazı kısımlarında değişiklik yapar ve modülü bozar. Daha da kötüsü, değişikliklerini test ediyorlar ve kodları çalışıyor, ancak modülünüzü test etmiyorlar; cehennem, modülünüzün var olduğunu bile bilmeyebilirler .

Ve şimdi bir sorunun var: kırık kod bagajda ve kimse bilmiyor bile. En iyi durum, dahili bir test cihazının gönderilmeden önce onu bulmasıdır, ancak oyunun sonlarında kodun düzeltilmesi pahalıdır. Ve eğer hiçbir dahili test cihazı bulamazsa ... bu çok pahalı olabilir.

Çözüm birim testlerdir. Kod yazarken sorun çıkarırlar - ki bu iyi - ama bunu elle yapmış olabilirsiniz. Gerçek getirisi, şu anda tamamen farklı bir proje üzerinde çalışırken dokuz ay boyunca sorunları yakalayacakları, ancak bir yaz stajyeri, bu parametrelerin alfabetik sırada olup olmadığını daha sonra daha düzgün görüneceğini düşünüyor. geri dönüşün başarısız olduğunu yazdınız ve birisi parametre sırasını değiştirene kadar stajyerde bir şeyler atar. Budur "neden" biriminin testleri. :-)

Birim testinin ve TDD'nin felsefi artılarını incelemek, TDD aydınlanmasına giden yoldaki ilk adımlarda beni etkileyen önemli "ampul" gözlemlerinden birkaçı (orijinal veya zorunlu olarak haber yok) ...

1. TDD, kodun iki katı yazmak anlamına gelmez. Test kodu genellikle yazmak için oldukça hızlı ve ağrısızdır ve tasarım sürecinizin önemli bir parçasıdır ve kritiktir.

2. TDD, kodlamayı ne zaman durduracağınızı anlamanıza yardımcı olur! Testleriniz, şimdilik yeterince yaptığınız konusunda güven veriyor ve ayarlamayı durdurabilir ve bir sonraki şeye geçebilir.

3. Daha iyi kod elde etmek için testler ve kod birlikte çalışır. Kodunuz kötü / hatalı olabilir. TEST'iniz kötü / buggy olabilir. TDD'de BOTH'un kötü / buggy olmasının oldukça düşük olma şansına sahip olursunuz. Sıklıkla düzeltilmesi gereken testtir, ancak bu hala iyi bir sonuçtur.

4. TDD, kabızlığın kodlanmasına yardımcı olur. Nereden başlayacağınızı bilmeniz için yapacak çok şeyiniz olduğunu biliyor musunuz? Cuma öğleden sonra, sadece birkaç saat daha ertelerseniz ... TDD yapmanız gerektiğini düşündüğünüz şeyi çok hızlı bir şekilde etmenize izin verir ve kodunuzu hızlı bir şekilde hareket ettirir. Ayrıca, laboratuar fareleri gibi, sanırım hepimiz o büyük yeşil ışığa cevap veriyoruz ve tekrar görmek için daha çok çalışıyoruz!

5. Benzer bir şekilde, bu tasarımcı türleri üzerinde çalıştıklarını görebilir. Bir meyve suyu / sigara / iphone molası için dolaşabilir ve onlara nereden geldiklerine dair görsel bir ipucu veren bir monitöre geri dönebilirler. TDD bize benzer bir şey veriyor. Hayat araya girdiğinde nereye gittiğimizi görmek daha kolay ...

6. Sanırım "Kusurlu testler, sık sık yapılan mükemmel testlerden hiç yazılmamış mükemmel testlerden çok daha iyi" diyen Fowler'dı. Bunu, kod kapsamımın geri kalanı acımasızca eksik olsa bile, en yararlı olacağını düşündüğüm testleri yazma izni olarak yorumluyorum.

7. TDD, her türlü şaşırtıcı şekilde yardımcı olur. İyi birim testleri, bir şeyin ne yapması gerektiğini belgelemeye yardımcı olabilir, kodu bir projeden diğerine taşımanıza yardımcı olabilir ve test dışı meslektaşlarınız üzerinde size garanti edilmeyen bir üstünlük hissi verebilir :)

Bu sunum , tüm nefis iyilik testlerine mükemmel bir giriş niteliğindedir.

Gerard Meszaros'un xUnit Testing Patterns kitabını tavsiye etmek istiyorum. Büyük ama birim testi için harika bir kaynak. Burada, birim testinin temellerini tartıştığı web sitesine bir bağlantı var. http://xunitpatterns.com/XUnitBasics.html

Zaman kazanmak için birim testleri kullanıyorum.

İş mantığı (veya veri erişimi) oluştururken test işlevselliği, genellikle henüz tamamlanabilecek veya tamamlanamayacak birçok ekrana bir şeyler yazmayı içerebilir. Bu testleri otomatikleştirmek zaman kazandırır.

Benim için birim testleri bir tür modüler test koşum takımıdır. Genel işlev başına genellikle en az bir test vardır. Çeşitli davranışları kapsayacak ek testler yazıyorum.

Kodu geliştirirken düşündüğünüz tüm özel durumlar birim testlerindeki koda kaydedilebilir. Birim testleri ayrıca kodun nasıl kullanılacağına dair bir örnek kaynak haline gelir.

Yeni kodumun birim testlerimde bir şey kırdığını ve ardından kodu kontrol edip bazı ön uç geliştiricilerin bir sorun bulmasını keşfetmem çok daha hızlı.

Veri erişim testi için, hiçbir değişiklik yapmayan veya kendileri temizleyen testler yazmaya çalışıyorum.

Birim testleri, tüm test gereksinimlerini çözemeyecektir. Geliştirme süresinden tasarruf edebilecek ve uygulamanın temel kısımlarını test edebileceklerdir.

Bu benim almam. Birim testi, gerçek yazılımınızın ne anlama geldiğini doğrulamak için yazılım testleri yazma uygulaması olduğunu söyleyebilirim. Bu , Java dünyasında jUnit ile başladı ve SimpleTest ve phpUnit ile PHP'de de en iyi uygulama haline geldi . Bu, Extreme Programming uygulamasının temel bir uygulamasıdır ve yazılımınızın düzenleme sonrasında hala amaçlandığı gibi çalıştığından emin olmanıza yardımcı olur. Yeterli test kapsamınız varsa, büyük yeniden düzenleme, hata düzeltme veya daha hızlı bir şekilde başka sorunlar getirme korkusu ile özellikler ekleyebilirsiniz.

Tüm birim testlerinin otomatik olarak yapılabilmesi en etkili yöntemdir.

Birim testi genellikle OO gelişimi ile ilişkilidir. Temel fikir, kodunuz için ortamı ayarlayan ve daha sonra kullanan bir komut dosyası oluşturmaktır; iddialar yazar, almanız gereken çıktıyı belirtir ve daha sonra yukarıda belirtilenler gibi bir çerçeve kullanarak test komut dosyanızı çalıştırırsınız.

Çerçeve, tüm testleri kodunuza göre çalıştıracak ve her testin başarılı veya başarısız olduğunu rapor edecektir. phpUnit varsayılan olarak Linux komut satırından çalıştırılır, bununla birlikte HTTP arayüzleri de vardır. SimpleTest, doğası gereği web tabanlıdır ve çalışmaya başlamak çok daha kolaydır, IMO. XDebug ile birlikte, phpUnit size bazı kullanıcıların çok faydalı bulduğu kod kapsamı için otomatik istatistikler verebilir.

Bazı takımlar, alt sürüm deposundan kancalar yazar, böylece değişiklik yaptığınızda birim testleri otomatik olarak yürütülür.

Birim testlerinizi uygulamanızla aynı havuzda tutmak iyi bir uygulamadır.

Kent Beck tarafından popüler olan TDD yaklaşımını kullanarak projelerinizi geliştirmek istiyorsanız , NUnit , xUnit veya JUnit gibi kütüphaneler zorunludur :

Test Odaklı Gelişim (TDD) veya Kent Beck'in Test Odaklı Gelişim: Örnek olarak adlı kitabını okuyabilirsiniz .

Daha sonra, testlerinizin kodunuzun "iyi" bir bölümünü kapsadığından emin olmak istiyorsanız, NCover , JCover , PartCover gibi yazılımları kullanabilirsiniz . Size kodunuzun kapsama yüzdesini söyleyeceklerdir. TDD'de ne kadar becerikli olduğunuza bağlı olarak, yeterince iyi çalışıp çalışmadığınızı bileceksiniz :)

Birim testi, kod biriminin dayandığı altyapıya ihtiyaç duymadan bir kod biriminin (örn. Tek bir işlev) test edilmesidir. yani tek başına test edin.

Örneğin, sınadığınız işlev bir veritabanına bağlanır ve bir güncelleştirme yaparsa, birim sınamasında bu güncelleştirmeyi yapmak istemeyebilirsiniz. Bir entegrasyon testi olsaydı, ama bu durumda değil.

Böylece birim testi, veritabanı güncellemesinin yan etkileri olmadan test ettiğiniz "işlev" içindeki işlevselliği uygular.

Fonksiyonunuzun bir veritabanından bazı sayılar aldığını ve daha sonra standart bir sapma hesaplaması gerçekleştirdiğini varsayalım. Burada ne test etmeye çalışıyorsun? Standart sapmanın doğru hesaplandığını veya verinin veritabanından döndürüldüğünü mü?

Birim testinde standart sapmanın doğru hesaplandığını test etmek istersiniz. Bir entegrasyon testinde standart sapma hesaplamasını ve veritabanı alımını test etmek istersiniz.

Birim testi, uygulama kodunuzu test eden kod yazmakla ilgilidir.

Birim adının bir parçası aynı anda Küçük kod birimleri test etmek amacıyla (örneğin, bir metodu) ile ilgilidir.

xUnit bu sınamada yardımcı olmaya hazırdır - bunlar buna yardımcı olan çerçevelerdir. Bunun bir kısmı, size hangi testin başarısız olduğunu ve hangilerinin geçtiğini söyleyen otomatik test koşuculardır.

Ayrıca, her testte elden önce ihtiyaç duyduğunuz ortak kodu ayarlayacak ve tüm testler bittiğinde yırtılacak olanaklara sahiptir.

Tüm catch komut bloğunu kendiniz yazmak zorunda kalmadan, beklenen bir istisnanın atıldığını kontrol etmek için bir test yapabilirsiniz.

Anlamadığınız nokta, NUnit (ve benzeri) gibi birim test çerçevelerinin küçük ve orta ölçekli testleri otomatikleştirmenize yardımcı olacağını düşünüyorum . Genellikle testleri bir GUI'de ( örneğin, NUnit'te olduğu gibi) sadece bir düğmeyi tıklatarak ve sonra - umarım - ilerleme çubuğunun yeşil kaldığını görebilirsiniz . Kırmızıya dönerse, çerçeve hangi testin başarısız olduğunu ve neyin yanlış gittiğini gösterir. Normal bir birim testinde, genellikle iddiaları kullanırsınız, örn Assert.AreEqual(expectedValue, actualValue, "some description").

Sonuç olarak birim testi, testlerin geliştiriciler için daha hızlı ve çok daha rahat olmasını sağlayacaktır. Yeni kod çalıştırmadan önce tüm birim testlerini çalıştırabilirsiniz, böylece aynı projedeki diğer geliştiricilerin oluşturma sürecini bozmazsınız.

Testivus kullanın . Bilmeniz gereken tek şey orada :)

Birim testi, uygulayacağınız işlevin veya modülün beklendiği gibi davranacağından (gereksinimler) ve ayrıca sınır koşulları ve geçersiz girdi gibi senaryolarda nasıl davrandığından emin olmak için bir uygulamadır.

xUnit , NUnit , mbUnit , vb. testleri yazmanıza yardımcı olan araçlardır.

Test Odaklı Geliştirme, Birim Testi terimini bir şekilde ele almıştır. Eski bir zamanlayıcı olarak bunun daha genel tanımından bahsedeceğim.

Birim Testi, daha büyük bir sistemde tek bir bileşenin test edilmesi anlamına da gelir. Bu tek bileşen bir dll, exe, sınıf kütüphanesi, vb olabilir. Çok sistemli bir uygulamada bile tek bir sistem olabilir. Sonuçta Birim Testi, daha büyük bir sistemin tek bir parçası olarak adlandırmak istediğiniz şeyin testi olur.

Daha sonra, tüm bileşenlerin birlikte nasıl çalıştığını test ederek entegre veya sistem testine geçersiniz.

Her şeyden önce, ister Ünite testi isterse başka türlü otomatik testler (Entegrasyon, Yük, UI testi vb.) Hakkında konuşun, önerdiğinizden en önemli fark, otomatik, tekrarlanabilir ve herhangi bir insan kaynağı gerektirmemesidir. (= hiç kimse testleri yapmak zorunda değildir, genellikle bir düğmeye basarak çalışırlar).

FoxForward 2007'de birim testi konulu bir sunuma gittim ve asla verilerle çalışan hiçbir şeyi test etmemem söylendi. Sonuçta, canlı veriler üzerinde test yaparsanız, sonuçlar tahmin edilemez ve canlı veriler üzerinde test yapmazsanız, aslında yazdığınız kodu test etmezsiniz. Ne yazık ki, bu günlerde yaptığım kodlamaların çoğu. :-)

Ayarları kaydetmek ve geri yüklemek için bir rutin yazarken son zamanlarda TDD'de bir çekim yaptım. İlk olarak, depolama nesnesini oluşturabildiğimi doğruladım. Sonra, aramam gereken yöntem vardı. Sonra, buna diyebilirim. Sonra, ben parametreleri geçebilir. Sonra, belirli parametreleri geçebilir ki. Ve böylece, nihayet belirtilen ayarı kaydedeceğini doğrulayana kadar, birkaç farklı sözdizimi için değiştirmeme izin verin ve sonra geri yükleyeceğim.

Sonuna gelmedim, çünkü şimdi rutin-şimdi-lanet'e ihtiyacım vardı, ama iyi bir egzersizdi.

Eğer bir saçmalık yığını verilirse ve herhangi bir yeni özellik veya kod eklenmesi ile bildiğiniz sürekli bir temizlik durumunda sıkışmış gibi görünüyorsa, mevcut yazılım bir ev gibi çünkü mevcut seti kırabilir kartlar?

Daha sonra birim testi nasıl yapabiliriz?

Küçük başlıyorsunuz. Yeni katıldığım projede birkaç ay öncesine kadar hiçbir birim testi yoktu. Kapsam bu kadar düşük olduğunda, kapsamı olmayan bir dosya seçer ve "test ekle" yi tıklarız.

Şu anda% 40'ın üzerine çıktık ve düşük asılı meyvelerin çoğunu almayı başardık.

(En iyi yanı, bu düşük kapsama düzeyinde bile, kodun yanlış şeyi yapan birçok örneğiyle zaten karşılaşmış olmamız ve testin yakalanmasıdır. Bu, insanları daha fazla test eklemeye iten büyük bir motivasyon kaynağıdır.)

Bu, neden birim test yapmanız gerektiğini yanıtlar.

Aşağıdaki 3 video, javascript dilinde birim testlerini kapsamaktadır, ancak genel ilkeler çoğu dilde geçerlidir.

Birim Testi: Dakikalar Artık Daha Sonra Saati Tasarruf Edecek - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

JS Birim Testi (çok iyi) - https://www.youtube.com/watch?v=-IYqgx8JxlU

Test Edilebilir JavaScript Yazma - https://www.youtube.com/watch?v=OzjogCFO4Zo

Şimdi sadece konuyu öğreniyorum, bu yüzden% 100 doğru olmayabilirim ve burada açıkladığımdan daha fazlası var, ancak birim testle ilgili temel anlayışım bazı test kodları yazmanızdır ( ana kod), ana kodunuzda, işlevin gerektirdiği giriş (bağımsız değişkenler) ile bir işlevi çağırır ve kod geçerli bir dönüş değeri alıp almadığını denetler. Geçerli bir değeri geri alırsa, testleri çalıştırmak için kullandığınız birim test çerçevesi yeşil bir ışık gösterir (hepsi iyi), değer geçersizse kırmızı bir ışık alırsınız ve sorunu hemen çözebilirsiniz. yeni kodu üretime bırakın, test etmeden aslında hatayı yakalayamamış olabilirsiniz.

Böylece geçerli kod için testler yazıp kodu testi geçecek şekilde yaratırsınız. Aylar sonra, sizin veya başka birinin ana kodunuzdaki işlevi değiştirmeniz gerekir, çünkü daha önce bu işlev için zaten test kodu yazmışsınızdır ve kodlayıcı işlevde bir mantık hatası eklediğinden veya tamamen bir şey döndürdüğünden test başarısız olabilir bu işlevin geri dönmesi gerekenden farklı. Yine test yapılmadan bu hatanın izlenmesi zor olabilir, çünkü muhtemelen diğer kodu da etkileyebilir ve fark edilmeyecektir.

Ayrıca, kodunuz üzerinden çalışan ve bunu yerine tarayıcı sayfasında elle sayfa yapmak yerine test eden bir bilgisayar programınız olması zaman kazandırır (javascript için birim testi). Bir web sayfasındaki bazı komut dosyaları tarafından kullanılan bir işlevi değiştirdiğinizi ve yeni amaç için iyi ve iyi çalıştığını varsayalım. Ancak, argümanların, kodunuzda düzgün çalışabilmesi için yeni değiştirilen işleve bağlı olan başka bir yerde daha başka bir fonksiyonunuz olduğunu da söyleyelim. Bu bağımlı işlev artık ilk işlevde yaptığınız değişiklikler nedeniyle çalışmayı durdurabilir, ancak bilgisayarınız tarafından otomatik olarak çalıştırılan sınamalar olmadan, gerçekten yürütülene kadar bu işlevle ilgili bir sorun olduğunu fark edemezsiniz ve sen'

Tekrarlamak gerekirse, uygulamanızı geliştirirken yürütülen testlere sahip olmak, kodlama yaparken bu tür sorunları yakalayacaktır. Testlerin yerinde olmaması, tüm uygulamanızı manuel olarak geçmeniz gerekecek ve o zaman bile hatayı tespit etmek zor olabilir, saf bir şekilde üretime gönderirsiniz ve bir süre sonra bir tür kullanıcı size bir hata raporu gönderir ( bir test çerçevesinde hata mesajlarınız kadar iyi olmayacaktır).

Konuyu ilk duyduğunuzda ve kendinize düşündüğünüzde oldukça kafa karıştırıcı, zaten kodumu test etmiyor muyum? Ve yazdığınız kod zaten "neden başka bir çerçeveye ihtiyacım var?" Diye çalışıyormuş gibi çalışıyor ... Evet, kodunuzu zaten test ediyorsunuz, ancak bir bilgisayar bunu yapmakta daha iyidir. Bir kez bir fonksiyon / kod birimi için yeterince iyi testler yazmanız yeterlidir ve geri kalanı sizin için güçlü cpu tarafından halledilir, bunun yerine bir değişiklik yaptığınızda tüm kodunuzun hala çalışıp çalışmadığını manuel olarak kontrol etmeniz gerekir. senin kodun.

Ayrıca, istemiyorsanız kodunuzu birim olarak test etmek zorunda kalmazsınız, ancak proje / kod tabanınız hata verme şansı arttıkça proje büyümeye başladığında işe yarar.

Birim testi ve TDD genel olarak, yazdığınız yazılım hakkında daha kısa geri bildirim döngüleri gerçekleştirmenizi sağlar. Uygulamanın sonunda büyük bir test aşamasına sahip olmak yerine, yazdığınız her şeyi kademeli olarak test edersiniz. Bu, hemen gördüğünüz gibi, hatalarınızın olabileceği kod kalitesini çok artırır.