Testle sürekli entegrasyon, her zaman "sevk edilebilir" kodunu kontrol ettiğinizden emin olmak için kullanışlıdır.
Bununla birlikte, kapsamlı bir test paketini sürdürmek gerçekten zordur ve genellikle, yapı yine de buggy olacak gibi hissettirir.
CI boru hattı testinize ne kadar güvenmeniz gerekiyor? Yeterli testin ne zaman yapılacağına karar vermek için bir tür metrik kullanıyor musunuz?
Yanıtlar:
Sürekli entegrasyon hattınıza güvenecek kadar otomatik testiniz ne zaman var?
Ne hakkında emin olmak istediğinizi düşünürseniz, cevap muhtemelen netleşir. Nihayetinde 1-1; her test sizi test ettiği tek şeyden emin yapar:
Sorunuzu formüle ettiğiniz yoldan, büyük olasılıkla şu anda büyük resimli bir iş anlayışıyla düşünüyorsunuz, örneğin:
Uygulamamın X yapabileceğinden emin olmak istiyorum .
Böylece X yapmaya çalışan ve bunu doğru yapıp yapmadığını kontrol eden bir uçtan uca test yazıyorsunuz.
Hepsi çok referanslıdır, ama bunun nedeni de budur. Orada sadece değil kendisine daha.
Örneğin, yemek tarifleri oluşturmak için bir uygulama yazdığınızı düşünün. Bir özellik, farklı miktarlarda birkaç çeşit peynir eklerseniz, size doğru sıcaklık ve zamanı verir, böylece hepsi erir.
Böylece CheeseMeltCalculator100g Gouda ve 200g Emmental peyniri için bir birim testi yazabilirsiniz ve daha sonra sıcaklık ve zamanın doğru olduğunu kontrol edin. Bu CheeseMeltCalculator, 100g Gouda ve 200g peynir için çalıştığından emin olabileceğiniz anlamına gelir . Yerine 200g Gouda 300g ile bu testi tekrar Şimdi, eğer sen olabilir oldukça emin farklı değerleri için doğru çalıştığından emin. Sen testleri ekleyebilir 0, -1ve int.MaxValueGouda gr kodu çelme vermediğinden emin olmak için (veya amaçlandığı gibi düzgün gezileri) garip girişi için.
CheeseMeltCalculatorTüm gıda sıcaklığı ve zaman hesaplama sürecine doğru bir şekilde dahil edildiğini kontrol etmek için bir entegrasyon testi yazabilirsiniz . Bu yanlış giderse, ancak CheeseMeltCalculatoryukarıdaki testler iyi ise, hatanın diğer hesap makinelerinde veya farklı hesap makinelerindeki verilerin birleştirilme biçiminde olduğundan emin olabilirsiniz.
Son olarak, tüm bir tarif oluşturmak için uçtan uca bir test yazabilirsiniz ve kontrol ettiğiniz şeylerden biri sonuç sıcaklığı ve süresidir. Önceki 2 test seviyesi iyiyse, ancak bunun için yanlış giderse, o parçaların doğru olduğundan emin olabilirsiniz ve hata, sıcaklık hesaplamasının uygulamaya nasıl entegre edildiği hakkında bir şeydir. Örneğin, kullanıcı girişi doğru şekilde aktarılmamış olabilir.
Ve son olarak , eğer bu testlerin hepsi iyi ise, o zaman " birkaç farklı türde peynir eklerseniz, size doğru sıcaklık ve zamanı verir, böylece hepsi erir "
Mesele şu ki, "doğru çalışıyor" testine sahip olamazsınız. Sadece "X yaparsam Y olur" testini yapabilirsiniz.
Ancak, bu tam olarak proje için teknik özelliklerde olması gereken şeylerdir. " Birkaç farklı türde peynir eklerseniz, size doğru sıcaklık ve zamanı verir, böylece hepsinin erimesini sağlar " gibi bir ifade, müşteriye sadece bitmiş ürünün ne yapacağına dair net beklentiler vermekle kalmaz, aynı zamanda döndürülebilir otomatik testlere
Kullanıcı Richard bu bilgileri bir düzenlemeye ekledi:
Martin Fowler, web sitesinde en yaygın stratejiler hakkında çok güzel bir özete sahiptir: https://martinfowler.com/articles/microservice-testing/
Bunu kaldırmak istemiyorum, ama şunu söylemek istiyorum: Bu cevaba kıyasla, bu bir "özet" değil, hoş grafikler ve her şeyle daha derinlemesine bir açıklama.
Benim tavsiyem şöyle olacaktır: Cevabımı okuduktan sonra her şey size mantıklı geliyorsa, işiniz bitmiştir. İşler hala belirsiz görünüyorsa, biraz zaman ayırın ve bağlantılı makaleyi okuyun.
Aradığınız güveni sağlayacak hesaplayabileceğiniz bir ölçüm yoktur. Güven bir şey yaparak ve daha sonra bunu başararak ya da başarısızlıkla ve ondan bir şey öğrenerek inşa edilir.
Test kapsamımda bana güven veren tek "metrikler":
Otomatik testler gümüş bir kurşun değildir. Her bir bırakma döngüsü sırasında kaç üretim hatası bulunduğunu takip etmeniz gerekir. Bu sayı düştüğünde daha iyi bir yazılım sunuyorsunuz. Otomatik testler ve Sürekli Entegrasyon yalnızca daha iyi yazılım sunmak için kullandığınız araçlardır .
Gerçekten ölçebileceğiniz tek metrik "Daha iyi bir yazılım mı sunuyorsunuz?"
Ve o zaman bile, özneldir.
Sürekli entegrasyon hattınıza güvenecek kadar otomatik testiniz ne zaman var?
Çoğu ekonomik ortamda, yeterli güveni uygulamak için bütçeniz olmayacaktır (>% 99), ancak sınırlı bir bütçeyi yönetmelisiniz: Her şey maliyet / fayda oranı ile ilgilidir.
Bu yüzden gerçekte kolay / ucuz / riskli testler uygulanacak, pahalı / olası olmayan testler uygulanmayacaktır.
Yazılım geliştirmenin bir alt hedefi, otomatikleştirilmiş testi uygun fiyata tutmak için test edilmesi kolay / ucuz ( Test-driven_development uygulayarak test edilebilirlik için tasarım) mimarisi yaratmaktır .
Pareto_prin prensibinin burada da korunabilir / test edilebilir yazılım için de uygulanabileceğini varsayıyorum :% 20 daha fazla para harcayarak% 80 ekstra fayda elde edeceğinizi söylüyor. Kalan% 20 daha fazla avantaja ulaşmak için ekstra% 80 para harcamanız gerekir.
Potansiyel olarak test edilmemiş kaynak kodunu göstermek için kod kapsamı ve mutasyon kapsamı gibi Test Metrikleri uygulayabilirsiniz .
Ancak% 100 kapsama alanı olsa bile, kodunuzun hata içermediğinden emin olamazsınız.
Yönetim, coetetrics'i sever. "Kod kapsamı> =% 80" yönetim tarafından zorlanıyorsa, geliştiriciler otomatikleştirilmiş testi desteklemiyor / beğenmiyorsa, yanlış bir güvenlik hissi veren hiçbir şeyi kanıtlamayan yüksek kapsama alanına sahip test kodu yazmanın yolları vardır.
Buradaki hile, tam kapsama alanı hakkında değil, değişikliklerinizin riskini yönetme konusunda endişelenmektir.
Boru hattınızı zaten Üretimdeki ile aynı sürümü dağıtmak için kullandığınızı varsayalım - regresyon hatası riski nedir? Sıfır (çünkü değişiklik yok).
Şimdi diyelim ki ekranlardan birinde bir metin parçası değiştirmek istiyorum. Metnin şimdi doğru bir şekilde görüntülendiğini doğrulamak için testi ekledim (argüman için gerçekten önemli bir metin parçası olduğunu varsayalım). Regresyon hatası olmadığını doğrulamak için başka hangi testlere ihtiyacım var? Gerçekten hiçbiri ...
Dolayısıyla, her sürümün yaşaması için gereken otomatik testlerin sayısı, uygulamanızın boyutunun değil, değişikliğinizin boyutudur. Küçük, düşük riskli değişiklikler yapıyorsanız, riskleri azaltmak için çok daha az teste ihtiyacınız olacaktır.
Ama bir dakika ... bu CI ve CD ile çok iyi uyuşmuyor mu?
Evet! Tüm değişikliklerinizi ve deltalarınızı çok küçük tutarak, regresyon risklerinin çoğunu test etmek yerine süreç yoluyla hafifletiyorsunuz. Dahası, soru aslında otomasyondan biri değil (sadece kullanacağımız araç) - sadece bir test ve risk iştahı meselesi. Otomasyonu tamamen unutun, bir değişikliğin sorun yaratmadığından emin olmak için bir değişikliğe karşı hangi testleri yapardınız? Bu sorunun cevabı manuel bir test sürecinden bir CI sistemine değişmez - tek avantajı, bu regresyon testlerinin birçoğunun daha önce işlevsellikte geliştirilmiş olması ve CI'nin sizi daha küçük ve daha güvenli değişiklikler yapmaya teşvik etmesidir.
TLDR
Testleriniz değişiklik riskini azaltmak içindir. Sıfır delta ile konuşlandırmanın herhangi bir riski yoktur ve bu nedenle herhangi bir risk taşımamaktadır. Değişikliklerinizi küçük tutarak onları doğrulamak için gerekli testleri tanımlamak çok daha kolay hale gelir - otomasyonun tekrar kullanılabilirliği bir avantajdır.
Ürününüzü manuel olarak test ettiğinizle aynı metriktir.
Pratik olarak, bu düşük güven bölgelerini tanımlamak kolaydır: Ürünü gönderdiğinizi varsayarsak, sevk edilebilirlik konusunda güveninizi artıran bazı boru hattı sonrası manuel adımlarınız olduğunu varsayalım. Bunlar, otomatik işlemin kendisine olan güveni artırmak için otomatikleştirmeniz gereken alanlardır.
Otomasyonunuz sürekli bir çabadır. Ürününüz geliştikçe büyür ve gelişir. Bir kusur, CI'yi yeniden etkinleştirmenin yanı sıra kodunuzu yeniden düşünmek için bir nedendir. Ve buradaki güneşli taraf, ürüne olan güvenin ulaşılabilir olması - otomasyona olan güvenin de elde edilebilir olmasıdır.