Birim testlerinin hızlı çalışmasını nasıl sağlayabiliriz?

Projemizde neredeyse bin testin yapıldığı noktaya ulaştık ve insanlar bir check-in yapmadan önce onları çalıştırma zahmetine son verdiler çünkü çok uzun sürüyor. En iyi ihtimalle değiştirdikleri kod parçası ile ilgili testleri yaparlar ve en kötüsü sadece test etmeden kontrol ederler.

Bu sorunun, çözümün 120 projeye ulaştığından (genellikle daha küçük projeler yaptığımız ve bu sadece TDD'yi ikinci kez yaptığımızdan) ve yapım + test süresinin yaklaşık iki-üç dakikaya ulaştığından kaynaklandığını düşünüyorum. daha küçük makinelerde.

Testlerin çalışma süresini nasıl kısaltırız? Teknik var mı Daha fazla numara mı yapıyorsun? Daha az numara mı yapıyorsun? Belki de tüm testleri çalıştırırken daha büyük entegrasyon testleri otomatik olarak çalışmamalıdır?

Düzenleme: cevapların birçoğunun yanıtı olarak zaten CI ve build server kullanıyoruz, testlerin başarısız olduğunu bu şekilde biliyorum. Sorun (aslında bir semptom) başarısız yapılar hakkında mesaj almaya devam ediyoruz. Kısmi testler yapmak çoğu insanın yaptığı ama hepsinin yapmadığı bir şeydir. ve testlerle ilgili olarak, aslında oldukça iyi yapılmışlar, her şey için sahte kullanıyorlar ve hiç IO yok.

Muhtemel bir çözüm, test bölümünü geliştirme makinelerinden sürekli bir entegrasyon kurulumuna ( örneğin, Jenkins ) bazı lezzetlerin sürüm kontrol yazılımını ( git , svn , vb. ) Kullanarak taşımak olacaktır .

Yeni kodun yazılması gerektiğinde, verilen geliştirici depoda ne yapıyorlarsa bir dal oluşturacaktır. Tüm çalışmalar bu branşta yapılacak ve ana kod satırını karıştırmadan istedikleri zaman şubede değişiklik yapabilirler.

Verilen özellik, hata düzeltme veya üzerinde çalıştıkları her şey tamamlandığında, tüm ünite testlerinin yapıldığı şubenin (veya bunu yapmayı tercih edersiniz) tekrar bagaja birleştirilmesi mümkündür. Bir test başarısız olursa birleştirme reddedilir ve geliştiriciye bildirilir, böylece hataları düzeltebilirler.

Ayrıca, CI sunucunuzun, her bir özellik dalında birim testleri yapıp, taahhütler vermesini sağlayabilirsiniz. Bu şekilde geliştirici bazı değişiklikler yapabilir, kodu kabul edebilir ve ek değişiklikler veya başka projeler üzerinde çalışmaya devam ederken sunucunun testleri arka planda çalıştırmasına izin verebilir.

Böyle bir kurulumu yapmanın bir yolunu gösteren harika bir kılavuz burada bulunabilir (özeldir ancak diğer sürüm kontrol sistemleri için çalışmalıdır): http://nvie.com/posts/a-successful-git-branching-model/

Birim Testlerinin çoğunluğu her biri ya da öylesine 10 milisaniyeden az sürmelidir. 'Neredeyse bin testleri' olması olduğunu şey ve almalı belki çalıştırmak için birkaç saniye.

Olmazsa, o zaman yüksek düzeyde birleştirilmiş entegrasyon testleri yazmayı bırakmalısınız (kodun gerektirmediği sürece) ve iyi birim testleri yazmaya başlayın (iyi bir şekilde ayrıştırılmış kodla başlayarak ve sahte / sahte / saplamalar / vb. Bu birleştirme test kalitesini ve bunları yazmak için gereken süreyi etkileyecektir - bu nedenle test çalıştırma süresini azaltma meselesi değildir.

Benzer sorunu çözmek için kullandığım birkaç yaklaşım var:

1. Yürütme zamanını kontrol edin ve en yavaş tüm testleri bulun ve yürütmek için neden bu kadar uzun sürdüklerini analiz edin .
2. 100 projeniz var, her seferinde onları inşa etmeye ve test etmeye gerek kalmayabilir mi? Bunların hepsini en ufak tefek bir gecede koşar mısın? Günlük kullanım için birkaç 'hızlı' yapı yapılandırması oluşturun . CI sunucusu, şu anki geliştirme sürecinizin 'sıcak' bölümleriyle ilgili sınırlı sayıda unittests projesi gerçekleştirecektir .
3. Yapabileceğiniz her şeyi alay edin ve yalıtın , mümkün olduğunda disk / ağ G / Ç işlemlerinden kaçının
4. Bu tür işlemleri izole etmek mümkün olmadığında, entegrasyon testleriniz olabilir mi? Entegrasyon testlerini yalnızca gece konstrüksiyonlarına programlayabilir misiniz ?
5. Örneklere / kaynaklara referans tutan ve belleği tüketen, ara sıra yapılan tüm tekilleri kontrol edin; bu, tüm testleri çalıştırırken performansın düşmesine neden olabilir.

Ek olarak, hayatınızı kolaylaştırmak ve testlerin daha hızlı çalışması için aşağıdaki araçları kullanabilirsiniz

1. Geçitli taahhüt, bazı CI sunucularının, kaynak havuzuna kod vermeden önce derleme ve test gerçekleştirme için yapılandırılabilir. Birisi daha önce tüm testleri çalıştırmadan kod verirse, bu da başarısız testleri içerir, reddedilir ve yazara geri gönderilir.
2. Testleri paralel olarak yürütmek için CI sunucusunu yapılandırın : birkaç makine veya işlem kullanarak. Örnekler pnunitve birkaç düğümlü CI konfigürasyonu.
3. Geliştiriciler için sürekli test eklentisi , tüm kodları otomatik olarak kod yazarken çalıştıracaktır.

0. Programlayıcılarınızı dinleyin.

Testleri yapmıyorlarsa, maliyetin (testlerin çalışmasını beklemek, yanlış başarısızlıklarla uğraşmak) değerden daha büyük (algılanan hataları yakalamak) algıladıkları anlamına gelir. Maliyetleri düşürün, değeri artırın ve insanlar testleri her zaman gerçekleştirecek.

1. Testlerinizi% 100 güvenilir yapın.

Yanlış negatif sonuçlarla başarısız olan testleriniz varsa hemen bununla başa çıkın. Onları düzeltin, değiştirin, ortadan kaldırın,% 100 güvenilirliği garanti etmek için ne gerekiyorsa yapın. (Ayrı olarak çalıştırabileceğiniz bir dizi güvenilmez, ancak yine de faydalı testler yapmanız uygundur, ancak testlerin ana gövdesi güvenilir olmalıdır.)

2. Tüm testlerin her zaman geçmesini sağlamak için sistemlerinizi değiştirin.

Yalnızca geçen komisyonların ana / resmi / serbest bırakma / ne olursa olsun dalına dahil edilmesini sağlamak için sürekli entegrasyon sistemlerini kullanın.

3. Kültürünüzü% 100 geçme sınavlarına göre değiştirin.

Testlerin% 100'ü geçene ve ana / resmi / serbest bırakma / ne olursa olsun dalla birleştirilene kadar bir görevin "bitmediği" dersini öğretin.

4. Testleri hızlı yapın.

Testlerin bir saniye sürdüğü projeler ve tüm gün sürdüğü projeler üzerinde çalıştım. Testlerin yapılması için geçen zaman ile verimliliğim arasında güçlü bir ilişki var.

Testler ne kadar uzun sürerse, onları o kadar az çalıştırırsınız. Bu, yaptığınız değişiklikler hakkında geri bildirim almadan daha uzun süre kalacağınız anlamına gelir. Ayrıca taahhütler arasında daha uzun süre gideceğiniz anlamına gelir. Daha sık çalışmak, birleştirilmesi daha kolay olan daha küçük adımlar anlamına gelir; taahhüt geçmişi takip etmek daha kolaydır; Tarihte bir hata bulmak daha kolaydır; geri almak da daha kolaydır.

O kadar hızlı çalışan testleri hayal edin ki, her derleyişinizde otomatik olarak çalıştırılmasının sakıncası yoktur.

Testleri hızlı yapmak zor olabilir (OP'nin istediği şey buydu!). Dekuplaj anahtarıdır. Sahte / sahte tamam, ama bence sahte / sahte gereksiz hale getirmek için refactoring yaparak daha iyisini yapabilirsiniz. Arlo Belshee'nin bloguna bakın, http://arlobelshee.com/post/the-no-mocks-book ile başlayın .

5. Testleri faydalı yapın.

Vidalarsan testler başarısız olursa, sorun ne? Yaratacağınız hataları yakalayacak testleri yazmayı kendinize öğretin. Bu kendi başına bir beceridir ve çok dikkat edecektir.

Birim testler için birkaç dakika tamam. Bununla birlikte, 3 ana test türü olduğunu unutmayın:

1. Birim testleri - her bir "birimi" (sınıf veya yöntem) projenin geri kalanından bağımsız olarak test edin
2. Entegrasyon testleri - genellikle programın çağrıları yaparak projeyi bir bütün olarak test edin. Gördüğüm bazı projeler bunu regresyon testleriyle birleştiriyor. Burada ünite testlerinden çok daha az alay konusu var
3. Regresyon testleri - Test paketi bir son kullanıcı olduğundan tamamlanan projeyi bir bütün olarak test edin. Bir konsol uygulamanız varsa, programı çalıştırmak ve test etmek için konsolu kullanırsınız. Dahili testleri bu testlere asla maruz bırakmazsınız ve programınızdaki herhangi bir son kullanıcı (teorik olarak) regresyon test takımınızı çalıştırabilmelidir (asla yapmasalar bile)

Bunlar hız sırasına göre listelenmiştir. Birim testleri hızlı olmalıdır. Her böceği yakalayamazlar, ancak programın makul derecede mantıklı olduğunu tespit ederler. Ünite testleri 3 dakika veya daha az veya uygun bir donanımda yapılmalıdır. Sadece 1000 ünite testi yaptığını ve 2-3 dakika sürdüğünü söylüyorsun. Peki, bu muhtemelen tamam.

Kontrol edilecekler:

• Ünite testlerinizin ve entegrasyon testlerinizin ayrı olmasına dikkat edin. Entegrasyon testleri her zaman daha yavaş olacaktır.

• Ünite testlerinizin paralel çalıştığından emin olun. Gerçek birim testleri olup olmadıklarına dair hiçbir sebep yoktur.

• Ünite testlerinizin "bağımlılık ücretsiz" olduğundan emin olun. Bir veritabanına veya dosya sistemine asla erişmemelidirler

Bunun dışında, testleriniz şu anda çok kötü gelmiyor. Bununla birlikte, referans olarak, arkadaşımın Microsoft ekibindeki biri iyi bir donanıma 2 dakikadan az bir sürede devam eden 4.000 birim testine sahip (ve bu karmaşık bir proje). Hızlı birim testleri yapmak mümkündür. Bağımlılıkların giderilmesi (ve yalnızca gerektiği kadar alay edilmesi) hızlanmanın ana yoludur.

Geliştiricilerinizi Kişisel Yazılım Süreci (PSP) konusunda daha fazla disiplin kullanarak performanslarını anlamalarına ve geliştirmelerine yardımcı olma konusunda eğitin . Kod yazmak, parmaklarınızı klavyeye çarpmakla ilgili değildir ve daha sonra bir derleme ve onaylama düğmesine basın.

PSP, kodu derlerken çok zaman alan bir işlem olduğunda geçmişte çok popülerdi (bir ana bilgisayarda saat / gün böylece herkes derleyiciyi paylaşmak zorunda kaldı). Ancak kişisel iş istasyonları daha güçlü hale geldiğinde, hepimiz süreci kabul etmeye geldik:

1. düşünmeden biraz kod yazın
2. derleme / derleme isabet
3. derlemek için yazımınızı düzeltin
4. yazdığın şeyin gerçekten mantıklı olup olmadığını görmek için testler yap

Yazmadan önce ve sonra yazdıktan sonra yazdıklarınızı gözden geçirirseniz, bir derleme ve deneme paketi çalıştırmadan önce hata sayısını azaltabilirsiniz. Günde 50 kez derlemeye basmamaya çalışın, ancak belki bir veya iki kez, o zaman derlemeniz ve test süreniz birkaç dakika daha uzun sürer.

Bir olası yol: çözümünüzü bölmek. Bir çözüm 100 proje varsa, o zaman oldukça yönetilemez. İki projenin (A ve B) başka bir projeden bazı ortak kodlar kullanması (Lib diyelim) aynı çözümde olmaları gerektiği anlamına gelmez.

Bunun yerine A ve Lib projeleriyle A çözümünü ve B ve Lib projeleriyle B çözümünü oluşturabilirsiniz.

Ben benzer bir durumdayım. Sunucuyla iletişimi test eden birim testlerim var. Davranışı zaman aşımına uğrayan, bağlantıları iptal eden vb. İle test ediyorlar. Testlerin tamamı 7 dakika sürüyor.

7 dakika nispeten kısa bir süre ancak her işlemden önce yapacağınız bir şey değil.

Ayrıca bir dizi otomatik kullanıcı arayüzü testimiz var, çalışma süreleri 2 saat. Bilgisayarınızda her gün çalıştırmak istediğiniz bir şey değil.

Peki ne yapmalı?

1. Testleri değiştirmek genellikle çok etkili değildir.
2. Taahhüdünüzden önce sadece ilgili testleri yapın.
3. Tüm testlerinizi her gün (veya günde birkaç kez) bir derleme sunucusunda çalıştırın. Bu ayrıca size güzel kod kapsamı ve kod analiz raporları oluşturma imkanı sunar.

Önemli olan şudur: Tüm testleriniz sık sık yapılmalıdır, çünkü hataları bulmak önemlidir. Ancak, onları komisyondan önce bulmak kesinlikle gerekli değildir.

Sorunla ilgili açıklamanız kod tabanına ilişkin ayrıntılı bir fikir vermese de, sorununuzun iki kat olduğunu güvenle söyleyebilirim.

Doğru testleri yazmayı öğrenin.

Neredeyse bin testin olduğunu ve 120 projen olduğunu söylüyorsun. Bu projelerin yarısının test projeleri olduğunu varsayarak, 60 üretim kodu projesine 1000 test yaptırdığınızı varsayalım. Bu size yaklaşık 16-17 test pr verir. Proje !!!

Muhtemelen bir üretim sisteminde yaklaşık 1-2 dersi kapsamam gereken testlerin miktarıdır. Bu nedenle, her bir projede sadece 1-2 sınıfınız yoksa (bu durumda proje yapınız çok ince taneli) testleriniz çok büyüktür, çok fazla zemin kaplar. Bunun TDD'yi doğru şekilde yaptığınız ilk proje olduğunu söylüyorsunuz. Bir deyiş, sunduğunuz sayılar, bunun böyle olmadığını, TDD özelliğini yapmadığınızı gösteriyor.

Doğru testleri yazmayı öğrenmeniz gerekir, bu muhtemelen ilk önce kodun nasıl test edilebilir hale getirileceğini öğrenmeniz gerektiği anlamına gelir. Bunu yapmak için takımın içindeki tecrübeyi bulamazsanız, dışarıdan yardım almanızı öneririm, örneğin ekibinize test edilebilir bir kod yazmayı öğrenmek için 2-3 ay boyunca ekibinize yardımcı olacak bir veya iki danışman şeklinde minimal birim testleri.

Karşılaştırma yapmak gerekirse, şu anda üzerinde çalışmakta olduğum .NET projesinde, 10 saniyeden daha az bir sürede yaklaşık 500 birim testini çalıştırabiliriz (ve bu, yüksek özellikli bir makinede bile ölçülmedi). Bunlar sizin figürleriniz olsaydı, bunları sık sık yerel olarak çalıştırmaktan korkmazsınız.

Proje yapısını yönetmeyi öğrenin.

Çözümü 120 projeye böldünüz. Bu benim standartlarım gereği şaşırtıcı miktarda projedir.

Bu nedenle, aslında bu kadar projeye sahip olmak mantıklı geliyorsa (ki bunu yapamayacağımı hissediyorum - ancak sorunuz bu konuda nitelikli bir değerlendirme yapmak için yeterli bilgi sağlamıyor), projeleri daha küçük bileşenlere ayırmanız gerekir. ayrı ayrı oluşturulabilir, sürümlendirilebilir ve dağıtılabilir. Bu nedenle bir geliştirici test paketini çalıştırdığında, yalnızca şu anda üzerinde çalıştığı bileşenle ilgili testleri çalıştırması gerekir. Derleme sunucusu her şeyin doğru şekilde entegre olduğunu doğrulamaya özen göstermelidir.

Ancak, bir projeyi birden fazla bileşene ayırmak, ayrı ayrı kurmak ve dağıtmak, tecrübelerime göre çok olgun bir geliştirme ekibi, ekibinizin olduğu hissine kapıldığımdan daha olgun bir ekip gerektiriyor.

Ancak her halükarda, proje yapısı hakkında bir şeyler yapmanız gerekiyor. Projeleri ayrı bileşenlere ayırın veya projeleri birleştirmeye başlayın.

Gerçekten 120 projeye ihtiyacınız olup olmadığını sorun.

ps NCrunch'u kontrol etmek isteyebilirsiniz. Testinizi otomatik olarak arka planda çalıştıran bir Visual Studio eklentisidir.

JUnit testi normalde hızlıdır, ancak bazılarının kazılara çıkması biraz zaman almalıdır.

Örneğin, veritabanı testinin başlatılması ve tamamlanması genellikle birkaç zaman alıyor.

Yüzlerce testiniz varsa, hızlı olsalar bile, sayıları nedeniyle çok fazla zaman harcarlar.

Ne yapılabilir:

1) Önemli testleri belirleyin. Kütüphanelerin en önemli kısımları için olanlar ve değişikliklerden sonra en çok başarısız olma ihtimalleri için olanlar. Sadece bu sınama her zaman derleme sırasında yapılmalıdır. Bazı kodlar sıklıkla bozulursa, yürütülmesi uzun sürse bile testleri zorunlu kılmalısınız, diğer taraftan, yazılımın bir kısmı hiçbir zaman bir soruna neden olmadıysa, her yapı için testleri güvenle atlayabilirsiniz.

2) Tüm testleri arka planda çalıştıracak olan sürekli entegrasyon sunucusunu hazırlayın. Her saat inşa etmeye karar verirseniz veya her taahhütten sonra inşa etmeye karar verirseniz size kalır (ikincisi, yalnızca kimin taahhüdünün soruna neden olduğunu otomatik olarak tespit etmek istiyorsanız anlamlıdır).

Gördüğüm konular:

a) Test elemanları oluşturmak için IOC kullanılması. 70 saniye -> 7 saniye Konteyner kaldırarak.

b) Tüm sınıflarla alay etmemek. Ünite testlerinizi tek bir elemanda tutun. Birkaç dersten geçebilecek testler gördüm. Bunlar birim test değildir ve kırılma olasılığı daha yüksektir.

c) Neler olduğunu öğrenmek için onları profillendirin. Yapıcının ihtiyaç duymadığım şeyleri inşa ettiğini buldum, bu yüzden yerelleştirdim ve çalışma sürelerini kısalttım.

d) Profil. belki de kod o kadar iyi değil ve incelemeden biraz verim alabilirsiniz.

e) Bağımlılıkları kaldırın. Testin çalıştırılabilir kük tutulması, yükleme süresini kısaltır. Son çözümünüzü çalıştırmak için bir arayüz kütüphanesi ve IOC kapsayıcıları kullanın, ancak ana test projelerinizde sadece tanımlanmış arayüz kütüphanesi bulunmalıdır. Bu ayırma sağlar, test etmenin daha kolay olmasını sağlar ve ayrıca test ayağınızın daha küçük basılmasını sağlar.

Acını hissediyorum ve yapım hızının çok fazla geliştirilebileceği birkaç yere rastladım. Ancak, önerdiğim şey , yapınızın en uzun sürdüğü yeri bulmak için ayrıntılı bir ayrıntıyla ölçmektir . Örneğin, yürütmek için bir dakikadan fazla süren yaklaşık 30 projeden oluşan bir yapıma sahibim. Ancak, bu resmin sadece bir kısmı. Ayrıca hangi projelerin inşa edilmesi en uzun sürdüğünü biliyorum, bu da çabalarıma odaklanmamda yardımcı oluyor.

Yemek yiyen şeyler zaman kazandırır:

• Paket indirme (C # için Nuget, Java için Maven, Ruby için Gem, vb.)
• Büyük miktarda dosyanın dosya sistemine kopyalanması (örnek: GDAL destek dosyaları)
• Veritabanına bağlantıların açılması (bazıları pazarlık için bağlantı başına bir saniyenizi alır)
• Yansıma tabanlı kod
• Otomatikleştirilmiş kod
• Program akışını kontrol etmek için istisnalar kullanma

Sahte kütüphaneler, sizin için sahtekarlık oluşturmak için bytecode kütüphanelerini kullanarak yansıma veya enjeksiyon kodunu kullanır. Çok uygun olmasına rağmen, test zamanı yiyor. Testinizde bir döngü içinde alay üretiyorsanız, ünite testlerine ölçülebilir bir süre ekleyebilir.

Sorunları çözmenin yolları var:

• Veritabanını içeren testleri entegrasyona taşıyın (yani yalnızca CI derleme sunucusunda)
• Testlerinizde döngüler içerisinde alay oluşturmaktan kaçının. Aslında, testlerinizdeki döngülerden tamamen kaçının. Bu durumda muhtemelen parametreli hale getirilmiş bir testi kullanarak aynı sonuçları elde edebilirsiniz.
• Büyük çözümünüzü ayrı çözümlere bölmeyi düşünün

Çözümünüz 100'den fazla proje içerdiğinde, bir kütüphane kodu, testler ve uygulama kodu kombinasyonuna sahipsiniz. Kütüphanelerin her biri, ilişkili testlerle kendi çözümü olabilir. Jet Brains Team City , Nuget sunucusu olarak işlev gören bir CI derleme sunucusudur - ve sadece bir tane olmadığından eminim. Bu, sık sık değişmeyen kütüphaneleri kendi çözümlerine / projelerine taşıma esnekliği verir ve Nuget'i uygulama kodunuzun bağımlılıklarını çözmek için kullanır. Daha küçük çözümler, bir kütüphanede değişikliklerinizi hızlı ve sorunsuz bir şekilde yapabileceğiniz ve ana çözümdeki avantajlardan yararlanabileceğiniz anlamına gelir.

Test ortamınız herhangi bir yerde çalışabilir mi? Mümkünse, testleri çalıştırmak için cloud computing kullanın. Testleri N sanal makineler arasında paylaştırın. Testlerin tek bir makinede çalıştırılma süresi T1 saniye ise, çalışma süresinin bölünmesi T2, T2 = T1 / N değerine yaklaşabilir. (Her bir test vakasının yaklaşık olarak aynı zaman alacağını varsayalım.) Ve yalnızca VM'leri kullanırken kullanmanız gerekir. Yani 7/24 bir yerde bazı laboratuarlarda oturan test makineleriniz yok. (Çalıştığım yerde bunu yapabilmeyi çok isterdim, ancak belirli donanıma bağlıyız. Benim için VM yok.)