Otomatik birim testinin iniş yöntemi, verimli ve yüksek kaliteli dağıtım zor değil!
Yazar Li Le
Düzenle Mu Huan
Otomatik birim testi yeni bir şey değil. Takımın devam ettiği bir şey olmalı. Bunu yapmayı bilen pek çok takım olabilir, ancak yeterince iyi performans göstermiyorlar; hala nasıl yapılacağını bilmeyen birçok takım var ve hatta bazı eski sistemler hala Yeniden düzenleme yapmaya cesaret edemedim, hala Java'da ana yöntemi çağırma konusunda ısrar ettim ve inşaat sonucunu uzun süre bekledim.
Bu makale esas olarak Java projelerine dayalı otomatik birim testi uygulamasından bahsediyor.
Değer mi
Birim testinin anlamı için stackoverflow hakkındaki bu makaleye bakın:
Martin Fowler, TestPyramid'i blogunda aşağıda gösterildiği gibi açıkladı:
Test Piramidi
Birim, tüm piramidin temel taşıdır (inşaat sektöründe köşe taşı binanın temeli olan taştır) Eğer köşe taşı dengesizse, Servis ve UI nasıl inşa edilebilir? Sadece temel taşı kaya kadar sağlamdır, üst yapı yeterince sağlamdır.
Göstermek için İsviçre saatleri ve saatleri örneğini kullanmak istedim, ancak meslektaşımın araba örneği daha iyi. Bir araba birçok aksesuardan oluşur.Aşağıda iki seçenek varsa hangisini seçerdiniz?
-
Tüm ünite aksesuarları test edilmemiştir 4S mağazasında satış personeli size şunu söyleyecektir: yeni monte edildi, bir gündür çalışıyor, deneyebilirsiniz;
-
Tüm ünite aksesuarları üretim sürecinde sıkı bir şekilde test edilmiştir.4S noktasında, satış personeli size ulusal sertifikasyonu geçtiklerini, kalifiye olduklarını ve kalite güvencelerine sahip olduklarını söyleyecektir, deneyebilirsiniz;
Cevap apaçık ortada.
Birim testi uygulamak, üretim verimliliğinizin hızla artabileceği anlamına gelmez, ancak bazen anında üretim verimliliğini engeller (bir işlevin geleneksel gelişimi, eylem tamamlanmış olsa bile, birim testi eklemek zaman kaybı gibi görünmüyor), ancak , En doğrudan olan şey, ürün kalitesini artırmak, böylece pazarın imajını iyileştirmektir ve dolaylı olarak üretim verimliliğini artıracaktır.
Ürünlerin miktarına mı yoksa kalitesine mi ihtiyacı var? Bu, şirketin uzun vadeli bir dayanağa ihtiyaç duyup duymadığını görmek için cevap verecek patronlara bırakılmalıdır.
önemli parçalar
Şekilde gösterildiği gibi, birleştirilecek otomatik birim testinin dört temel bileşeni vardır:
Anahtar bileşen
(1) Yapılandırma yönetimi: sürüm kontrolünü kullanın
Bir sürüm kontrol sistemi (kaynak kodu kontrol yönetim sistemi), dosyaların birden çok sürümünü depolamak için bir mekanizmadır. Genel olarak konuşursak, Subversion ve Git gibi açık kaynaklı araçlar çoğu ekibin ihtiyaçlarını karşılayabilir. Tüm sürüm kontrol sistemlerinin bu kadar basit bir sorunu çözmesi gerekir: Sistemin, kullanıcıların yanlışlıkla birbirlerine müdahale etmelerine izin vermeden bilgileri paylaşmalarına izin vermesi nasıl sağlanır?
Sürüm kontrol araçlarının yardımı olmadan, geliştirme aşamasında sıklıkla aşağıdaki sorunlarla karşılaşıyoruz:
-
Kod yönetimi karmaşıktır.
-
Kod çakışmalarını çözmek zordur.
-
Kod entegrasyonu sırasında derin HATA tanıtın.
-
Kod sahibinin yetkisi kontrol edilemiyor.
-
Projenin farklı versiyonlarını yayınlamak zor.
Her şeyin sürüm kontrolü
Sürüm kontrolü yalnızca kaynak kodu için değildir.Geliştirilen yazılımla ilgili her ürün, sürüm kontrolü altına alınmalıdır. Aşağıdakileri içermelidir: kaynak kodu, test kodu, veritabanı komut dosyaları, oluşturma ve dağıtım komut dosyaları, belgeler, web kapsayıcıları (tomcat Yapılandırma) kullanılan yapılandırma dosyaları vb.
Omurgaya güvenilir kodun sık sık sunulmasını sağlayın
Güvenilir ve kalite garantili kodun sık sık gönderilmesi (derleme en temel gereksinimdir), kod gönderildikten sonra kolayca en son güvenilir sürüme geri dönebilir, sürekli entegrasyon oluşturmayı tetikleyebilir ve zamanında geri bildirim alabilir.
Anlamlı yorumlar gönderin
Ekip üyelerinin anlamlı yorumlar ve hatta ilgili geliştirme görevlerini kullanmalarının gerekmesinin nedeni şudur: yapı başarısız olduğunda, yapıyı kimin kırdığını, olası nedeni ve kusur yerini bulmayı bilirsiniz. Bu ek bilgiler, kusurları onarmak için süremizi kısaltabilir.
Örnek: Takım svn ve redmine kullanıyor ve yorum şu şekildedir: refs #task id gönderme talimatları
Her görevin altında birden çok gönderim kaydı görebilirsiniz:
İlgili revizyonlar
-
Tüm kod dosyası kodlama formatları, UTF-8'i aynı şekilde kullanır
-
İşe gitmeden önce kodu güncelleyin, işten önce kodu gönderin
Bir gün önce, ekibin diğer üyeleri svn'ye çok sayıda kod göndermiş olabilir. Yeni bir iş gününe başlamak için, sorunları (kod çakışmaları gibi) zamanında keşfedip çözmek için en son sürüme güncellediğinizden emin olun;
Aynı gün, gün bittiğinde, günün kodlama sonuçlarını yalnızca işten sonra yerel olarak kaydetmeyin. Bunu svn'ye göndermelisiniz. Ekip, ertesi gün en son sürümü güncelleyerek erdemli bir çember oluşturabilir.
Yapı yönetimi: Maven derleme araçlarını kullanın
Maven, Java projesinin kod organizasyon yapısı için açıklama bilgilerini tanımlayarak projenin yapımını, raporlamasını ve dokümantasyonunu yöneten Proje Nesne Modeli'ne (POM) dayalı bir yazılım proje yönetim aracıdır. "Konfigürasyon yerine kongre" (konfigürasyon yerine konvansiyon) ilkesini kullanarak, proje Maven'in yaptığı şekilde organize edildiği sürece, birçok XML satırı yazmadan, tek bir komutla oluşturma, dağıtma ve test etme gibi neredeyse tüm görevleri gerçekleştirebilir. (Ant dosyalarındaki birçok standart dosyayı ortadan kaldırın).
Belki de Ant'ı inşa etmek için kullanan ekip, neden Maven'i kullanalım diye soracaktır. Kısacası, üç neden var:
1. Üçüncü tarafa bağlı kitaplıkların birleşik sürüm yönetimi
Dürüst olmak gerekirse, karınca bağımlı paketler arasındaki çatışmalarla ilgilenir ve yine de manuel olarak çözülmesi gerekir.Bu, Ar-Ge için zaman alıcıdır. Ayrıca, her proje için spring.jar'ı sıkıcı bir şekilde kopyalamak artık gerekli değildir.Java kütüphaneleri ve projeler arasındaki bağımlılıklar otomatik olarak maven aracılığıyla yönetilir ve tüm kavanozlar, paketleme sırasında WEB-INF / lib / dizinine kopyalanır.
2. Projenin dizin yapısını birleştirin.
Tüm projelerin dizin yapısının herhangi bir sunucuda aynı olduğundan ve her dizinin rolünün çok açık olduğundan emin olun.
3. Birleşik yazılım oluşturma aşaması
Maven2, yazılım geliştirme sürecini birkaç klasik aşamaya ayırır.Örneğin, biraz java kodu oluşturmanız, ardından kodu belirli bir konuma kopyalamanız, ardından kodu derlemeniz, sınıf yolunun altına yerleştirilmesi gereken kaynakları kopyalamanız ve ardından birim testi yapmanız gerekir. Ancak birim testleri geçtikten sonra paketlenebilir ve serbest bırakılabilir.
(Üç) test çerçevesi: JUnitMockito
JUnit
JUnit, bir Java dil birimi test çerçevesidir.
2013'te eski bir proje gördüm. Test kodu hala giriş olarak main kullanıyor.Neden JUnit kullanmalı?
JUnit'in avantajı, tüm test sürecinin gözetimsiz olmasıdır.Geliştirme, çevrimiçi katılım gerektirmez ve nihai sonucun doğru olup olmadığına karar vermez.Bir seferde birden fazla test çalıştırmak kolaydır, bu da geliştirmeyi, inşaat ve bakım süresini artırmak yerine test mantığını yazmakla daha ilgili hale getirir.
Takım örnek kodu:
Mockito
Mockito, Java için alaycı bir çerçevedir. Temiz ve güzel test senaryoları ve basit API'ler yazmak için kullanın. EasyMock ve jMock'a çok benzer. Yürütmeden sonra neyin çağrıldığını doğrulayarak beklenen davranışlara (beklentilere) olan ihtiyacı ortadan kaldırır ve diğer alaycı kitaplıkları "kayıt oynatma" (çirkin koda yol açar) test akışına dönüştürür. , Kendi dilbilgisini doğal dile daha çok benzetiyor.
Mockito örneği:
EasyMock örneği:
(4) Geri bildirim platformu: JenkinsSonar
Sürekli entegrasyon platformu: Jenkins
Jenkins'in öncülü, esas olarak şunlar için kullanılan, genişletilebilir bir sürekli entegrasyon motoru olan Hudson'dur:
-
Sürekli ve otomatik olarak test yazılımı projeleri oluşturun
-
Bazı zamanlanmış görevleri izleyin
Jenkins, otomatik inşaatı gerçekleştirmek için otomatik birim testi için sürekli bir entegrasyon platformu olarak kullanılacak.
Jenkins platformu
Kod kalitesi yönetimi platformu: Sonar
Sonar (SonarQube), kaynak kodunun kalitesini yönetmek için açık kaynaklı bir platformdur. Sonar yalnızca kaliteli bir veri raporlama aracı değil, aynı zamanda bir kod kalitesi yönetimi platformudur. Desteklenen diller şunlardır: Java, PHP, C #, C, Cobol, PL / SQL, Flex vb.
ana özellik:
-
Kod kapsamı: Birim testini geç, hangi kod satırının seçildiğini gösterecektir
-
Kodlama kurallarını iyileştirin
-
Kodlama kurallarını arayın: ada, eklentiye, etkinleştirme seviyesine ve kategoriye göre arama yapın
-
Proje arama: proje adına göre sorgulama
-
Verileri karşılaştırın: aynı tablodaki herhangi bir ölçümün eğilimini karşılaştırın
Sonar, aşağıdakiler dahil olmak üzere otomatik birim testi geri bildirim raporları için birleşik bir görüntüleme platformu olarak hizmet verecektir:
Sonar, aşağıdakiler dahil olmak üzere otomatik birim testi geri bildirim raporları için birleşik bir görüntüleme platformu olarak hizmet verecektir:
Birim test kapsamı, başarı oranı, kod yorumları ve kod karmaşıklığı gibi ölçüm verilerinin görüntülenmesi.
Sonar platformu
Prensibi takip edin
Otomatikleştirilmiş hiyerarşik test olarak da bilinen otomatik test piramidi, Birim tüm piramidin temel taşıdır.En önemli özellik çok hızlı çalışmasıdır; ikinci önemli özellik UT'nin kod tabanının çoğunu kapsaması gerektiğidir ve UT geçtikten sonra belirlenebilir, Uygulama normal şekilde çalışacaktır.
Birim:% 70, çoğunlukla otomatik, tek bir işlevin veya bağımsız işlev modülünün kodunu doğrulamak için kullanılır;
Hizmet:% 20, iki veya daha fazla modül veya hatta daha fazla modül arasındaki entegrasyon testini içerir;
UI:% 10, üç veya daha fazla işlevsel modülü kapsayan, gerçek kullanıcı senaryoları ve verilerinin kabul testi;
Burada her seviyenin sadece yüzdesi listelenmiştir ve gerçek ayarlama ekibin yönüne göre yapılmalıdır.
Otomatik Birim Testinin İlkeleri
Kod göndermenin ve testleri çalıştırmanın amacı nedir? Değişiklikler nedeniyle sistemde ortaya çıkan en yaygın hataları hızlı bir şekilde yakalayın ve bunları hızlı bir şekilde düzeltebilmeleri için geliştiricilere bildirin. Gönderim aşamasında geri bildirim sağlamanın değeri, ona yapılan yatırımın sistemin verimli ve daha hızlı çalışmasını sağlamasıdır.
UI işlemlerini izole edin
UI, daha yüksek bir test seviyesi seviyesi olarak kullanılmalıdır, verileri hazırlamak çok zaman alır, iş mantığı karmaşıktır, UI aşamasına çok erken girilir, geliştirme birimi test çabasını dağıtmak kolaydır.
Veritabanını ve dosya okuma ve yazma ağ ek yükünü ve diğer işlemleri izole edin
Otomatik testte, sonuçları veri tabanına yazmanız ve ardından değiştirilen sonuçların doğru yazılıp yazılmadığını doğrulamanız gerekiyorsa, bu doğrulama yöntemi basit ve anlaşılması kolaydır, ancak etkili bir yöntem değildir. Bu, entegrasyon testi seviyesinden çözülmelidir.
Her şeyden önce: Veritabanıyla etkileşim uzundur ve veritabanının bakımı bile zaman alabilir, bu da hızlı testin önünde bir engel teşkil eder ve geliştiriciler zamanında ve etkili geri bildirim alamazlar. Diyelim ki, veritabanı ile etkileşimin sonuçlarını doğrulamak için bir saat harcamam gerekiyor, bu beklemenin ne kadar sürdüğü.
İkinci olarak, veri yönetimi, veri taramasından (çevrimiçi veriler T düzeyi olabilir) test ortamının M düzeyine, uygun boyutun nasıl filtreleneceğine kadar, yönetim maliyetini artıran maliyet gerektirir (tabii ki, DBUnit'i kullanarak Bazı problemleri çözün).
Son olarak, okuyan ve yazan bir test olması gerekiyorsa, tamamlanabilir, kodun test edilebilirliğine ne dersiniz? Yeniden düzenlemeye ihtiyacınız var mı?
Birim testi, veritabanı, dosya sistemi ve ağ ek yükü gibi tüm harici bağımlılıklara dayanmamalıdır.
Spring konteynerinden izole etmek için Mock avatarını kullanın
Birim testindeyse, bağımlılık enjeksiyonu, yüke bağlı WebService, vb. İçin Spring konteynerini de başlatmanız gerekir. Bu işlem oldukça zaman alır.
Problemi çözmek için simülasyon araç setini kullanabilirsiniz: Mockito, EasyMock, JMock, vb.Ar-Ge ekibi esas olarak Mockito uygulamasına dayanmaktadır. Birleştirilmesi gereken tüm bağımlılıklar ve durumlarla karşılaştırıldığında, simülasyon teknolojisini kullanan testler genellikle çok hızlıdır, böylece geliştiriciler kodu gönderdikten sonra sürekli entegrasyon platformu hakkında hızla geri bildirim alabilirler.
Basit testler tasarlayın
Yöntemi açıkça tanımlayın:
Başarı: public void testSendReportLongDateSuccess
Hata: istisnalar içerebilen public void testSendReportLongDateFail
Ve tek bir iddia, bir yöntemde kod yapısının karmaşıklığına neden olacak ve testin karmaşıklığını artıracak çok sayıda karmaşık iddia kullanmaktan kaçının.
Test paketinin çalışma süresini tanımlayın
Mock ile oluşturulan birim testler için her yöntemin yapım süresi milisaniye, tüm sınıf saniyeler içinde olmalıdır.İdeal olarak genel yapım süresi 5 dakika içinde kontrol edilmelidir.Ya aşarsa?
İlk olarak, birden çok pakete bölün ve bu paketleri birden çok makinede paralel olarak yürütün;
İkinci olarak, daha uzun süre çalışan ve sıklıkla başarısız olan test sınıflarını yeniden düzenleyin;
