“Testin erken yayınlanması sık sık” ortamında Birim Testinin önemi nedir?

Son bir yıl boyunca, ekibimi serbest bırakma-erken-serbest bırakma-sıklıkla geliştirme tarzına (AKA: Hızlı Uygulama Geliştirme, Çevik değil) doğru yönlendirdim. Yapıyı kapatma şeklimiz hakkında daha fazla bilgi için buradaki cevabım bölümüne bakın: RAD ortamında sürüm kalitesini iyileştirmenin basit yolları

RAD'ı benimsediğimizde, insanlar oldukça bağımsızdılar ve önce birim testi yapıyorlardı; entegre testler bu süreçte çok sonra gerçekleşti. Resmi bir uygulama olmaksızın onlar için doğal bir süreçti. Şimdi durum oldukça farklı:

1. Tüm platform, herhangi bir sıcak nokta olmadan istemci tarafında çalışan yerleşik yapılarla / sürümlerle iyi bir şekilde entegre edilmiştir.

2. Yeni işlevsellik gereksinimleri gelmeye devam ediyor ve gittikçe kademeli olarak oluşturuyoruz.

3. Sistemin genel dinamikleri çok önemlidir, çünkü bağımsız kalkınma grupları süreçleri doğru takip etse de, karmaşık ve açık olmayan durumlar nedeniyle büyük hatalar ortaya çıkmıştır.

4. Sistemin birçok parçası yeni algoritmalar ve araştırma girdileri içerir, bu nedenle iyi tanımlanmış yazılımlarda özellik testi gibi zorluklar (ve dolayısıyla test mekanizması) her zaman doğru şekilde öngörülmez.

Son zamanlarda, süreç iyileştirmeye ihtiyacımız olup olmadığını görmek için genel olarak daha iyi bir resim elde etmeye çalışıyordum. Ekibimle oturduğumda, birçoğu alkışladı: "Artık birim testi yapmıyoruz!" diğerleri ise şimdi başlamamamız gerektiğini düşünürken, asla etkili olmayacak.

Birim testleri nispeten olgun bir sistemde faydalı mıdır? En azından birimlerin olgunluğuna bağlı olarak test kapsamını tartmamız gerekir mi? Birim testi, geliştirme hızını yavaşlatacak mı? Birim testini farklı bir şekilde değerlendirmeye ihtiyaç var mı?

Sürüm-erken-sürüm-sıklıkla bir ortamda olgun bir platform için test etmenin en iyi uygulamaları nelerdir?

Birim testleri öncelikle hataları bulmak için değildir - sisteminizin bir sonraki sürümünün bir önceki sürüm kadar kararlı olmasını sağlamak içindir. Serbest bırakma döngünüz ne kadar kısa olursa, bu testleri manuel olarak yapmak yerine otomatik olarak çalıştırabilmeniz o kadar önemli olur.

Tabii ki, bazı bağımsız parçalara sahip bir sisteminiz varsa ve sistemin sadece küçük bir bölümünde iki sürüm arasında çalışıyorsanız, muhtemelen sistemin diğer parçaları için olan bazı birim testlerini atlayabilirsiniz. Ancak, çalıştığınız parçalar için birim testlerini kesinlikle kullanmalısınız (ve uzatmalısınız).

Başka bir şey, bir sistem büyüdüğünde ek entegrasyon testlerine gittikçe daha fazla ihtiyaç duyulacağıdır - ancak bu daha az birim testine ihtiyacınız olacağı anlamına gelmez.

Arkanızdaki gerçek soru belki de farklı olabilir. Sisteminiz büyüdükçe birim testleri yazmak zorlaştı mı? "Birim" testleriniz gerçekten birim testler mi, yoksa artık hiçbir şeyi tek başına test etmiyorlar mı? Bunun nedeni, sistemin zaman içinde stabilize olan daha alt düzey parçalarına güvenmeleri olabilir.

Bunlar, geliştiricilerin mevcut kütüphaneleri ve kodları doğrudan referans alarak yeniden kullanma eğilimi gösterdikleri için olur. Genellikle daha karmaşık bir ortam ve daha fazla test verisi sağlamaları gerektiğinden, yazma birimi testlerinin zorlaşması etkisine sahiptir. Sorununuz buysa , kodu daha birim-test edilebilir hale getirmenize yardımcı olabilecek Bağımlılık Enjeksiyonu ve Arabirim Ayrışma İlkesi gibi temel kavramları öğrenmelisiniz .

Testlerin önce tasarlandığı test odaklı geliştirmeyi incelemeyi ve yeni kodun yazıldığında nasıl çalışacağını açıklamalısınız. Daha sonra testleri geçersiniz.

Deneyimlerime göre bu, özellikle kütüphaneler için daha yalın ve daha iyi düşünülmüş bir kod yapma eğilimindedir ve şartnamenin çalıştırılabilir bir parçasıdır (yani her zaman doğru belgeler olacaktır).

Bununla birlikte, mevcut testler kodun hala beklendiği gibi çalışmasını sağlamak için kullanılır . Kod kırılmasını yakalayabilir ve yükseltme sırasında üçüncü taraf kodunun beklendiği gibi çalıştığından emin olmanızı sağlar.

Doc Brown ve Thorbjørn Ravn Andersen tarafından önerildiği gibi , Release Release erken sürüm ortamı, iyi ünite testleri ve test odaklı geliştirmelerden uzun sürüm döngülerine göre daha fazla fayda sağlayabilir .

İyi bir Sürekli entegrasyon sisteminiz ve işlevselliği iyi temsil eden testleriniz varsa, neyin işe yaradığını (çünkü bu işlevsellik için testler geçtiği) ve henüz uygulanmayan ( çünkü bu işlevsellik için test yoktur).