Ünite testlerine karşı uçtan uca testler, testler çözülmeli midir?

Şirketimizde genellikle web sitelerimiz / web uygulamalarımız için uçtan uca bir test yazdığımızdan emin oluruz. Bu, bir URL’ye erişeceğimiz, bir form dolduracağımız, formu başka bir URL’ye gönderdiğimiz ve sayfanın sonuçlarını kontrol ettiğimiz anlamına gelir. Bunu form doğrulamasını test etmek, HTML şablonlarının doğru içerik değişkenlerine sahip olduğunu test etmek için yaparız.

Ayrıca, temel mantığı dolaylı olarak test etmek için de kullanıyoruz.

Bir meslektaşım tarafından bunun nedeninin, uçtan uca testler geçtiği sürece herhangi bir noktada söküp değiştirebileceğimiz olduğu söylendi.

Bu tür bir ayrıştırmanın bir anlam ifade edip etmediğini veya daha küçük kod birimleri için test yazmaktan kaçınmanın bir yolu olup olmadığını merak ediyorum.

Uçtan uca testler de gereklidir. Tüm birimleri birlikte doğru şekilde bağladığınızı nasıl bilebilirsin? Çok basit kodda, tüm yolları yalnızca uçtan uca testlerle kod üzerinden test etmek mümkündür, ancak daha fazla katman elde ettikçe, bunu yapmak daha da zorlaşır.

Örneğin, her biri beş olası yolu olan üç katmanınız olduğunu varsayalım. Tüm yolları tüm uygulama boyunca test etmek için 5 ³ uçtan uca test gerekir, ancak tüm yolları sadece 5 · 3 birim testleriyle test edebilirsiniz. Yalnızca uçtan uca test yaparsanız, çoğu hata işleme ve sınır koşullarında birçok yol ihmal edilir.

Evet, uçtan uca testler (veya entegrasyon testleri) çok anlam ifade eder, ancak birim testleri de yapar. İdeal olarak, her ikisine de sahip olursunuz, çünkü her ikisi de tipik olarak farklı tür böcekleri yakalar. Bu nedenle, uçtan uca testlere sahip olmak asla ünite testlerine sahip olmamak için bir bahane olmamalıdır.

Birkaç yıl kod yazıp projeler üzerinde çalıştıktan sonra kendi soruma cevap vereceğim.

Evet, birim testleri yazmalısın. Uçtan uca testler özellikle UI bileşenlerine güveniyorlarsa yazmaları ve kırılganlıkları daha zordur.

Django veya Rails (ya da kendi özel sınıflarınız) gibi bir çerçeve kullanıyorsanız, formun geçerliliğini kaldıracak bir form sınıfınız olmalıdır. Ayrıca, oluşturulan şablonları ve formu görüntüleyip GET ve POST isteklerini işleyen sınıfları göreceksiniz.

Testi bitirmek için sonunda:

1. URL'yi al
2. formu geçerli verilerle doldurun
3. formu URL’ye gönderin
4. Veritabanının güncellendiğinden veya geçerli formun bir sonucu olarak bazı işlemlerin yapıldığından emin olmak için kontrol edin.

Çok fazla kod test ediyorsunuz ve kapsamınız oldukça iyi olacak ancak her şey yolunda giderken sadece mutlu yolu deniyorsunuz. Formun içinde doğru doğrulamanın olmasını nasıl sağlarsınız? Ya bu form birden fazla sayfada kullanılıyorsa? Testi bitirmek için başka bir son yazıyor musun?

Bunu birim testleriyle tekrar deneyelim:

1. görünüm GET yöntemini test et
2. Görünüm POST yöntemini sahte / sahte bir formla sınama
3. formu geçerli verilerle test edin
4. formu geçersiz verilerle test edin
5. formun yan etkilerini test eder

Birim testlerini kullanarak, daha küçük kod parçalarını test ediyorsunuz ve testler özel ve yazması daha kolay. Bunu TDD (Test Driven Development) ile birleştirdiğinizde daha yüksek kalite kodu elde edersiniz.

Eğer bir proje üzerinde olduğunuzda çünkü birim testleri yazma kolaylığı göz ardı edilmemelidir hiçbir otomatik test, sen bir yere başlamak zorunda. Ünite testlerine başlamak daha kolay ve daha hızlıdır ve sadece mutlu yoldan ziyade hatalar için hemen teste başlamanızı sağlar.

Aslında uçtan uca testler veya entegrasyon testleri, tamamen çalışan bir sisteme sahip olduğunuzdan emin olduklarından ünite testlerinden daha önemlidir. Ünite testleri, özellikle büyük projelerde karmaşık bir görev olan sistemin entegrasyon kısmını kapsamaz.

Bununla birlikte, söylendiği gibi, ünite testi de yapmalısınız, çünkü entegrasyon testinde son durumları yakalamak daha karmaşıktır.

Sistem davranışını doğrularken, birim testleri birim davranışını doğrular. Her biri için fayda ve maliyetler farklıdır. Birini veya diğerini veya her ikisini de yapabilirsiniz.

Yaptığım işte tarif ettiğinize benzer bir ünite testi olmadan Kabul Testi Odaklı Geliştirme yapıyoruz. Hem zaman içinde hem de zamanla yapmaya başladık, sonunda bizim için faydaları aşan maliyete yapılan testlerden kurtulduk.

Bence, sorun alanınız ve ortamınız için maliyet / fayda, herhangi bir geliştirme uygulamasında, farklı otomatik test uygulamalarında yer alma kararlarını yönlendirmelidir. İnancım yerine, tüm uygulamaların onları desteklemek için orada kullandıkları bağlamda ampirik kanıtlara sahip olmasını tercih ederim.