Mevcut bir uygulama için birim sınamaları yazmakla görevlendirildim. İlk dosyamı bitirdikten sonra, 419 satır orijinal kod için 717 satır test kodum var.

Kod kapsamımızı artırdıkça bu oran yönetilemez mi?

Birim sınama anlayışı, her yöntemin beklendiği gibi çalıştığından emin olmak için sınıftaki her yöntemi sınamaktı. Ancak, çekme talebinde, teknik liderim daha üst seviye testlere odaklanmam gerektiğini belirtti. Her bir işlevi ayrıntılı bir şekilde test etmekten ziyade, söz konusu sınıfla en sık kullanılan 4-5 test durumlarını kullanmasını önerdi.

Teknoloji liderimin yorumuna güveniyorum. Benden daha fazla deneyime sahip ve yazılım tasarlama konusunda daha iyi içgüdüleri var. Ancak çok kişilik bir ekip böyle belirsiz bir standart için nasıl test yazar? yani, meslektaşlarımı nasıl tanırım ve “en yaygın kullanım durumları” için aynı fikri paylaşıyorum?

Bana göre,% 100 birim test kapsamı yüksek bir hedef, ancak sadece% 50'ye ulaşsak bile,% 50'nin% 100'ünün kapsandığını biliyorduk. Aksi takdirde, her dosyanın bir kısmı için test yazmak hile yapmak için çok fazla alan bırakır.

Evet,% 100 doluluk oranıyla ihtiyacınız olmayan bazı testleri yazacaksınız. Ne yazık ki, hangi testlere ihtiyacınız olmadığını belirlemenin tek güvenilir yolu hepsini yazmak, sonra hangilerinin başarısız olduğunu görmek için 10 yıl kadar beklemek.

Çok fazla test yapmak genellikle problemli değildir. Birçok ekip,% 100 birim test kapsamı üzerine otomatik entegrasyon ve sistem testleri gerçekleştirmiştir.

Ancak, bir test bakım aşamasında değilsiniz, yetişiyorsunuz. Derslerin% 100'ünü% 50 test kapsamı altında tutmak% 100 test kapsamındaki sınıflarınızın% 50'sinden çok daha iyidir ve lideriniz zamanınızı buna göre ayırmaya çalışıyor gibi görünmektedir. Bu taban çizgisine sahip olduktan sonra, bir sonraki adım, ileriye doğru değiştirilen dosyalarda genellikle% 100'dür.

Test Driven Development kullanılarak oluşturulan büyük kod tabanları üzerinde çalıştıysanız, çok fazla ünite testi gibi bir şey olabileceğini zaten bilirdiniz. Bazı durumlarda, geliştirme çabalarının çoğu çalışma zamanında ilgili sınıflarda değişmez, önkoşul ve sonkoşul kontrolleri olarak uygulanabilecek düşük kaliteli testlerin güncellenmesinden oluşur (örneğin daha yüksek seviye testinin yan etkisi olarak test etme) ).

Başka bir sorun, test edilecek şeylerin çoğalmasına neden olan (daha fazla sınıf, arayüz vb.), Kargo-kültüre dayalı tasarım tekniklerini kullanarak düşük kaliteli tasarımların yaratılmasıdır. Bu durumda, yük test kodunu güncelliyor gibi görünebilir, ancak asıl sorun kalitesiz tasarımdır.

Sorularınızın cevapları

Çok fazla birim testi yaptırmak gibi bir şey var mı?

Elbette ... Örneğin, ilk bakışta farklı gibi görünen ancak aynı şeyi gerçekten test eden birden fazla test yapabilirsiniz (mantıksal olarak test edilen "ilginç" uygulama kodunun aynı satırlarına bağlıdır).

Ya da kodunuzun içini, asla dışlanmayacak şekilde test edebilirsiniz (yani, herhangi bir arayüz sözleşmesinin bir parçası değildir), bunun bir anlam ifade edip etmediği konusunda tartışabilir. Örneğin, dahili log mesajlarının tam ifadesi veya her neyse.

Mevcut bir uygulama için birim sınamaları yazmakla görevlendirildim. İlk dosyamı bitirdikten sonra, 419 satır orijinal kod için 717 satır test kodum var.

Bu beni oldukça normal vuruyor. Testleriniz kurulum için çok sayıda kod satırı harcıyor ve gerçek testlerin üstüne yazıyor. Oran gelişebilir veya artmayabilir. Ben kendimi oldukça ağır test ediyorum ve genellikle testlere asıl koda göre daha fazla yer ve zaman harcıyorum.

Kod kapsamımızı artırdıkça bu oran yönetilemez mi?

Oran çok fazla etkiye sahip değil. Bunları yönetilemez hale getirme eğiliminde olan başka test nitelikleri de vardır. Kodunuzda oldukça basit değişiklikler yaparken düzenli olarak bir sürü testte tekrar test yapmak zorunda kalırsanız, nedenlerine iyi bir şekilde bakmalısınız. Bunlar ne kadar çizginiz olduğunu değil, testlerin kodlanmasına nasıl yaklaştığınızı gösterir.

Birim sınama anlayışı, her yöntemin beklendiği gibi çalıştığından emin olmak için sınıftaki her yöntemi sınamaktı.

Bu kesinlikle "birim" testleri için doğrudur. Burada “birim” bir yöntem veya sınıf gibi bir şeydir. "Birim" testinin amacı, tüm sistemi değil sadece belirli bir kod birimini test etmektir. İdeal olarak, sistemin geri kalanının tamamını kaldırmanız gerekir (çiftler ya da değiller kullanarak).

Ancak, çekme talebinde, teknik liderim daha üst seviye testlere odaklanmam gerektiğini belirtti.

Sonra insanlara aslında varsayarak tuzağına düştü geliyordu onlar ne zaman birim testleri söyledi birim testleri. "Birim testi" diyen ancak oldukça farklı bir şey ifade eden birçok programcı ile tanıştım.

Her bir işlevi ayrıntılı bir şekilde test etmekten ziyade, söz konusu sınıfla en sık kullanılan 4-5 test durumlarını kullanmasını önerdi.

Elbette, sadece önemli kodun% 80'ine yoğunlaşmak da yükü azaltır ... Patronunuz hakkında çok düşündüğünüz için minnettarım, ancak bu beni en iyi seçenek olarak görmüyor.

Bana göre,% 100 birim test kapsamı yüksek bir hedef, ancak sadece% 50'ye ulaşsak bile,% 50'nin% 100'ünün kapsandığını biliyorduk.

"Birim test kapsamı" nedir bilmiyorum. "Kod kapsamı" demek istediğinizi varsayalım, yani test takımını çalıştırdıktan sonra, her kod satırının (=% 100) en az bir kez yürütüldüğünü varsayalım.

Bu güzel bir basketbol sahası ölçüsüdür, ancak şu ana kadar çekebilecek en iyi standart değildir. Sadece kod satırlarını çalıştırmak bütün resim değildir; bu, örneğin karmaşık, iç içe geçmiş dallar arasındaki farklı yolları hesaba katmaz. Parmağını çok az test edilen kod parçalarına işaret eden bir metriktir (açıkçası, eğer% 10 veya% 5 kod sınıfı olarak bir sınıf varsa, o zaman bir şeyler yanlış olur); Öte yandan,% 100'lük bir garanti size yeterince test edip etmediğinizi veya doğru test edip etmediğinizi söylemez.

Entegrasyon testi

Günümüzde insanlar sürekli olarak birim testinden bahsederken, beni varsayılan olarak rahatsız ediyor . Benim düşünceme göre (ve deneyimlerim), birim testi kütüphaneler / API'ler için mükemmeldir; Daha çok iş odaklı alanlarda (elimizdeki sorudaki vakaları kullanırsak), mutlaka en iyi seçenek değildir.

Genel uygulama kodu ve ortalama işlerde (para kazanmanın, son teslim tarihlerine ulaşmanın ve müşteri memnuniyetini sağlamanın önemli olduğu ve esas olarak doğrudan kullanıcının yüzüne giren veya gerçek felaketlere yol açabilecek hatalardan kaçınmak istediğiniz) - NASA'nın roket konuşması burada başlar), entegrasyon veya özellik testleri çok daha faydalıdır.

Bunlar Davranış Odaklı Gelişme ya da Özellik Odaklı Gelişme ile el ele gider; bunlar tanımı gereği (katı) birim testleri ile çalışmaz.

Kısa tutmak için (ish), bir entegrasyon / özellik testi tüm uygulama yığınını kullanır. Web tabanlı bir uygulama olarak, tarayıcı uygulaması yoluyla tıklayarak (ve hayır, belli ki değil gibi davranırdım var kontrol - o basit olması, bunu yapmak için orada çok güçlü çerçeveler vardır // salatalık: http. Bir örnek için io ).

Son sorularınızı cevaplamak için: yeni bir özelliğin ancak özellik testi uygulandıktan ve başarısız olduktan sonra programlandığından emin olarak tüm ekibinizin yüksek test kapsamına girmesini sağlayın. Ve evet, bu her özellik demek . Bu size% 100 (olumlu) özellik kapsamı garanti eder . Tanım gereği, uygulamanızın bir özelliğinin asla "kaybolmayacağını" garanti eder. % 100 kod kapsamı garantisi vermez (örneğin, negatif özellikleri etkin bir şekilde programlamadığınız sürece hata işleme / istisna işlemlerinizi gerçekleştirmezsiniz).

Size hatasız uygulama garantisi vermez; Tabii ki, açık ya da çok tehlikeli buggy durumları, yanlış kullanıcı girişi, bilgisayar korsanlığı (örneğin, çevre oturum yönetimi, güvenlik ve benzeri) vb. için özellik testleri yazmak isteyeceksiniz; ancak, sadece pozitif testlerin programlanması bile muazzam bir avantaja sahiptir ve modern, güçlü çerçevelerle oldukça uygulanabilir.

Özellik / entegrasyon testleri açıkça kendi solucan kutularına sahiptir (örneğin, performans; 3. parti çerçevelerin fazladan test edilmesi; genellikle çift kullanmazsınız çünkü benim tecrübelerime göre yazmak daha zor olma eğilimindedirler ...) d Her gün% 100 kod kapsama birimi test edilmiş bir uygulama (kütüphane değil!) üzerinden% 100 pozitif özellik testli bir uygulama yapın.

Evet, çok fazla ünite testi yapmak mümkündür. Ünite testleri ile% 100 kapsama alanınız varsa ve örneğin entegrasyon testleri yoksa, açık bir sorun yaşarsınız.

Bazı senaryolar:

1. Testlerinizi belirli bir uygulamaya göre aşırı geliştiriyorsunuz. Daha sonra, yeniden uygulama yaparken ünite testlerini atmanız gerekir, uygulamanın ne zaman değiştiğini söylememek zorunda değilsiniz (performans optimizasyonları yaparken çok sık görülen bir ağrı noktası).

   Ünite testleri ve entegrasyon testleri arasındaki iyi denge, önemli bir kapsamı kaybetmeden bu sorunu azaltır.

2. Yaptığınız testlerin% 20'si ile tüm taahhütler için makul bir güvenceye sahip olabilirsiniz, kalan% 80'i entegrasyon için veya en azından ayrı test geçişleri bırakarak; Bu senaryoda gördüğünüz en önemli olumsuz etkiler, testlerin yürütülmesi için uzun süre beklemek zorunda olduğunuzdan dolayı yavaş değişikliklerdir.

3. Test etmenize izin verecek kadar çok kod değiştiriyorsunuz; örneğin, hiçbir zaman değiştirilmemesi gereken bileşenlerde IoC'nin kötüye kullanıldığını gördüm ya da en azından bunların genelleştirilmesi maliyetli ve düşük bir önceliktir, ancak insanlar bunları birimlerin test edilmesine izin vermek için genelleme ve yeniden düzenleme için çok zaman harcıyorlar. .

Dosyaların% 50'sinin% 100'ünü kapsama önerisini özellikle% 50'sini kapsama önerisini kabul ediyorum; başlangıçtaki çabalarınızı en yaygın pozitif durumlara ve en tehlikeli olumsuz durumlara odaklayın; önemli olmadıkları için değil, sınırlı bir zamanınız ve sınırsız bir test evreniniz olduğu için hata işleme ve olağandışı yollara çok fazla yatırım yapmayın. bu yüzden her durumda öncelik vermen gerekiyor.

Her testin bir faydasının yanı sıra bir maliyeti olduğunu unutmayın. Dezavantajları şunlardır:

• bir test yazılmalıdır;
• bir testin çalışması (genellikle çok az miktarda) zaman alır;
• bir test kodla korunmalıdır - test edilen API'ler değiştiğinde testler değişmelidir;
• Bir test yazmak için tasarımınızı değiştirmeniz gerekebilir (bu değişiklikler genellikle daha iyisi için olsa da).

Maliyetler faydalardan ağır basarsa, bir testin yazılmaması daha iyidir. Örneğin, eğer işlevselliği test etmek zorsa, API sık sık değişir, doğruluk nispeten önemsizdir ve testin bir kusur bulma şansı düşüktür, muhtemelen yazmamakta daha iyidir.

Özel testlerinizin kod oranına gelince, eğer kod yeterince mantık yoğun ise, o zaman bu oran garanti edilebilir. Bununla birlikte, muhtemelen tipik bir uygulama boyunca bu kadar yüksek bir oranı korumaya değmez.

Evet, çok fazla birim testi gibi bir şey var.

Test iyi olsa da her birim testi:

• API'ye sıkıca bağlı olan potansiyel bir bakım yükü

• Başka bir şeye harcanabilecek zaman

• Unit Test paketinde bir zaman dilimi
• Gerçek bir değer katmıyor olabilir, çünkü asgari şansa sahip başka bir testin kopyası, başka bir testin geçmesi ve bu testin başarısız olması gibi.

% 100 kod kapsamı hedeflemek akıllıca olacaktır, ancak bunun dışında, her biri bağımsız olarak belirli bir giriş noktasında (işlev / yöntem / çağrı vb.)% 100 kod kapsamı sağlayan bir test paketi anlamına gelir.

Her ne kadar iyi bir kapsama alanı elde etmenin ve hataların giderilmesinin ne kadar zor olduğu düşünüldüğü halde, muhtemelen “çok fazla birim testi” kadar “yanlış birim testi” diye bir şey olduğu söylenebilir.

Çoğu kod için pragmatik:

1. % 100 giriş noktası kapsamına sahip olduğunuzdan emin olun (her şey bir şekilde test edilir) ve 'hata olmayan' yolların% 100 kod kapsamına yakın olmasını hedefleyin.

2. İlgili min / max değerlerini veya boyutlarını test edin

3. Komik bir özel durum olduğunu düşündüğünüz her şeyi test edin, özellikle 'tuhaf' değerler.

4. Bir hata bulduğunuzda, bu hatayı açığa çıkaran ve benzer vakaların eklenip eklenmeyeceğini düşünecek bir ünite testi ekleyin.

Daha karmaşık algoritmalar için ayrıca şunları göz önünde bulundurun:

1. Daha fazla vaka için toplu testler yapıyoruz.
2. Sonucu bir 'kaba kuvvet' uygulaması ile karşılaştırmak ve değişmezleri kontrol etmek.
3. Rastgele test senaryoları üretmek ve değişmezler dahil kaba kuvvet ve post-koşullara karşı kontrol etmek için bazı yöntemler kullanmak.

Örneğin, bazı randomize girişlere sahip bir sıralama algoritmasını kontrol edin ve verilerin doğrulanması, tarama yaparak en sonunda sıralanır.

Teknik direktörünüzün 'minimum çıplak kıç' testi önerdiğini söyleyebilirim. 'En yüksek değer kalite testi' teklif ediyorum ve aralarında bir spektrum var.

Belki de kıdemli üyeleriniz oluşturduğunuz bileşenin daha büyük bir parçaya gömüleceğini ve entegre edildiğinde daha ayrıntılı test edildiğini biliyor.

Temel ders, böcek bulunduğunda testler eklemektir. Bu bana ünite testleri geliştirmekle ilgili en iyi dersimi veriyor

Alt birimlere değil birimlere odaklanın. Alt ünitelerden bir ünite inşa ediyorsanız, alt üniteler için makul olana kadar çok temel testler yazın ve alt üniteleri kontrol üniteleri ile test ederek daha iyi kapsama elde edin.

Öyleyse bir derleyici yazıyorsanız ve bir sembol tablosu yazmanız gerekiyorsa (örneğin). Sembol tablosunu hazırlayın ve basit bir testle çalışın ve masayı dolduran bildirim çözümleyici üzerinde çalışın (diyelim). Sembol tablosundaki 'bağımsız' üniteye yalnızca daha fazla test ekleyiniz. Aksi halde, bildirim ayrıştırıcısındaki birim testleriyle ve daha sonra tüm derleyicinin kapsamını artırın.

Paranın karşılığını en iyi şekilde alır (bütünün bir testi birden fazla bileşeni test eder) ve yeniden tasarım ve arıtma için daha fazla kapasite bırakır, çünkü daha kararlı olma eğiliminde olan testlerde yalnızca 'dış' arayüz kullanılır.

Hata ayıklama kodu testi ön koşulları ile birleştiğinde, her seviyedeki değişmezleri içeren post-koşullar, minimum test uygulamasından maksimum test kapsamı alır.

Öncelikle, üretim kodundan ziyade daha fazla test hattına sahip olmak sorun değil . Test kodu doğrusaldır ve anlaşılması kolaydır (veya olması gerekir) - üretim karmaşıklığı olsun olmasın, gerekli karmaşıklığı çok, çok düşüktür. Eğer karmaşıklık testlerinin, üretim kodu o yaklaşmaya başlar o zaman büyük olasılıkla bir sorun var.

Evet, çok fazla birim test yapmak mümkündür - basit bir düşünce deneyi, ek değer sağlamayan testler eklemeye devam edebileceğinizi ve tüm bu testlerin en azından bazı yeniden alevlendirmeleri engelleyebileceğini göstermektedir.

Bence, sadece en yaygın vakaları test etme önerileri hatalı. Bunlar sistem test zamanından tasarruf etmek için duman testleri gibi davranabilir, ancak gerçekten değerli testler tüm sistemde egzersiz yapmak zor olan vakaları yakalar. Örneğin, kontrollü bellek ayırma hatalarının hatalı enjeksiyonu, aksi takdirde tamamen bilinmeyen kalitede olabilen kurtarma yollarını kullanmak için kullanılabilir. Ya da bir bölen (ya da karekökülenecek negatif bir sayı) olarak kullanılacak bir değer olarak sıfıra geçin ve işlenmeyen bir istisna alamadığınızdan emin olun.

Bir sonraki en değerli testler aşırı sınırları veya sınır noktalarını kullanan testlerdir. Örneğin, yılın (1 tabanlı) ayını kabul eden bir işlev 0, 1, 12 ve 13 ile test edilmelidir, bu nedenle geçerli geçersiz geçişlerin doğru yerde olduğunu bilirsiniz. Bu testler için 2..11 kullanmak da aşırı testtir.

Zor bir durumdasınız, çünkü mevcut kod için testler yazmak zorundasınız. Son durumları kodu yazarken (veya yazmak üzere) tanımlamak daha kolaydır.

Birim sınama anlayışı, her yöntemin beklendiği gibi çalıştığından emin olmak için sınıftaki her yöntemi sınamaktı.

Bu anlayış yanlıştır.

Birim testleri, test edilen birimin davranışını doğrular .

Bu anlamda, bir birimin mutlaka “bir sınıfta bir yöntem” olması gerekmez. Birim tanımını Roy Osherove'in The Unit of Art Test'de tanımlamasını seviyorum :

Birim, değişmek için aynı nedene sahip olan üretim kodunun tümüdür.

Buna dayanarak, bir birim testi kodunuzun istenen her davranışını doğrulamalıdır . “Arzunun” şartlardan az ya da çok alındığı durumlarda

Ancak, çekme talebinde, teknik liderim daha üst seviye testlere odaklanmam gerektiğini belirtti.

Haklı, ama düşündüğünden farklı bir şekilde.

Sorunuzdan, o projedeki "özel testçi" olduğunuzu anlıyorum.

Büyük yanlış anlama, birim testleri yazmanızı beklemesidir ("birim test çerçevesi kullanarak test etme" nin aksine). Birim testler yazmak, test edicilere değil geliştiricilerin sorumluluğudur (ideal bir dünyada biliyorum ki ...). Öte yandan, bu soruyu TDD ile etiketlediniz, bu da tam olarak bunu ifade ediyor.

Test cihazı olarak göreviniz, modül ve / veya uygulama testlerini yazmak (veya elle yürütmek). Ve bu tür testler temel olarak tüm birimlerin birlikte sorunsuz çalıştığını doğrulamalıdır. Bu, test durumlarınızı seçmeniz gerektiği için her birimin en az bir kez çalıştırılacağı anlamına gelir . Ve bu kontrol şu ki, işte bu. Gerçek sonuç, gelecekteki gerekliliklerle değişime tabi olduğu için daha az önemlidir.

Damperli otomobil analojisini bir kez daha vurgulamak için: Montaj hattının sonunda bir otomobille kaç test yapıldı? Tam olarak bir: park alanına tek başına gitmeli ...

Buradaki nokta şudur:

"Ünite testleri" ile "ünite test çerçevesi kullanılarak otomatikleştirilmiş test" arasındaki farkın farkında olmamız gerekir.

Bana göre,% 100 birim test kapsamı yüksek bir hedef, ancak sadece% 50'ye ulaşsak bile,% 50'nin% 100'ünün kapsandığını biliyorduk.

Birim testleri bir güvenlik ağıdır. Teknik borcu azaltmak ya da daha önce uygulanmakta olan davranışları bozmaktan korkmadan yeni davranışlar eklemek için kodunuzu yeniden yapılandırmanız konusunda size güven veriyorlar .

% 100 kod kapsamına ihtiyacınız yok.

Ancak% 100 davranış kapsamına ihtiyacınız var. (Evet, kod kapsamı ve davranış kapsamı bir şekilde ilişkilidir, ancak bunun uğruna aynı değildir.)

% 100'den az davranış kapsamınız varsa, test takımınızın başarılı bir şekilde çalıştırılması denenmemiş davranışlardan bazılarını değiştirebileceğinizden hiçbir şey ifade etmez. Ve serbest bırakılmanızın çevrimiçi hale gelmesinden bir gün sonra müşteriniz tarafından fark edileceksiniz ...

Sonuç

Birkaç test, test yapmamaktan iyidir. Şüphesiz!

Ancak çok fazla birim testi yapmak gibi bir şey yoktur.

Bunun nedeni, her birim testinin kod davranışı hakkında tek bir beklentiyi doğrulamasıdır . Ayrıca, kodunuzdan beklentilerinizden daha fazla birim testi yazamazsınız. Ve emniyet kemerinizdeki bir delik, istenmeyen bir değişikliğin üretim sistemine zarar vermesi için bir şanstır.

Kesinlikle evet. Eskiden büyük bir yazılım şirketi için SDET oldum. Küçük ekibimiz, daha büyük bir ekip tarafından kullanılan test kodunu korumak zorunda kaldı. Bunun da ötesinde, ürünümüzün sürekli kırılma değişiklikleri getiren bazı bağımlılıkları vardı, bu da bizim için sürekli test bakımı anlamına geliyordu. Takım boyutunu arttırma seçeneğimiz yoktu, bu yüzden başarısız olduklarında binlerce daha az değerli testi atmak zorunda kaldık. Aksi takdirde, asla kusurlara yetişemeyiz.

Bunu sadece bir yönetim sorunu olarak görmeden önce, gerçek dünyadaki birçok projenin eski statülerine yaklaşırken personel alımında azalma olduğunu düşünün. Bazen ilk sürümden hemen sonra gerçekleşmeye başlar.

Ürün kodundan daha fazla test kod satırına sahip olmak mutlaka bir sorun değil, kopya yapıştırmayı ortadan kaldırmak için test kodunuzu yeniden düzenlediğinizi varsayalım.

Sorun, uygulamanızın bir aynası olan testler yapmak, ticari bir anlamı yoktur - örneğin, sahte ve taslaklarla yüklü testler ve sadece bir yöntemin başka bir yöntem dediğini iddia etmek.

"Neden çoğu birim testinin israf olduğu" makalesindeki harika bir alıntı , birim testlerinin "geniş, resmi, bağımsız bir doğruluk ve ... atfedilebilir işletme değerine" sahip olması gerektiğidir.

Bahsetmediğim bir şey , herhangi bir geliştiricinin herhangi bir zamanda çalışması için testlerinizin hızlı ve kolay olması gerektiğidir .

Değişikliklerin bir şeyleri kırıp kırmadığını görmek için testler tamamlanmadan önce kontrol etmek ve bir saat veya daha fazla (kod tabanınızın boyutuna bağlı olarak) beklemek zorunda kalmazsınız - bunu yapabilmek istersiniz. Kaynak kontrolü için check-in yapmadan önce kendi makineniz (ya da en azından değişikliklerinizi yapmadan önce). İdeal olarak, sınamalarınızı tek bir komut dosyası veya düğmeye basma ile çalıştırabilmeniz gerekir.

Ve bu testleri yerel olarak gerçekleştirdiğinizde, saniyeler içerisinde hızlıca çalışmalarını istersiniz. Herhangi bir yavaş, ve onları yeterince ya da hiç çalıştırmak için cazip olacaksınız.

Bu yüzden, hepsini çalıştıran birçok test yaptırmak dakikalar alır veya aşırı karmaşık testlerden birkaçını yapmak sorun olabilir.