Testler Yaz: Temeller
Testler, yüksek kaliteli ve sürdürülebilir yazılım geliştirme için önemli bir unsurdur. Ama neden tam olarak testler bu kadar önemli, avantajları nelerdir ve taahhütleri için hangi nedenlerden bahsediyorlar? Alternatif olarak elle test edemez misiniz?
Testlerin alaka düzeyi ile ilgili soruya sık sık bahsedilen bir cevap, yazılımın istendiği gibi çalıştığından emin olabilmenizdir. Prensip olarak, bu yanlış değil, aslında ikincil.
Testlerin, bugün yarın olduğu gibi eşit olarak gerçekleştirilebilecekleri için, istemsiz değişikliklere karşı bir güvenlik ağı olarak hareket etmesi çok daha önemlidir. Yol boyunca, operasyonun zaten bozulma riskini üstlenmeden kodun genişlemesine ve ekine izin verirler. Böylece uzun vadeli stabilite ve kaliteye katkıda bulunurlar.
Bunu yapmak için, testleri otomatik olarak gerçekleştirebilmek önemlidir, çünkü ancak o zaman kod tekrarlanabilir, belirleyici ve hızlı olabilir. Teorik olarak, testler de düşünülebilir olacaktır, ancak bu nedenle bahsedilen üç yönün hepsi artık mevcut değildir. Tabii ki, testlerin başlangıçta tüketilmesinin zamanı geldi – ancak özellikle uzun vadede, çaba aynı zamanda çok daha yüksek güvenilirliğe sahip manuel testlerden önemli ölçüde daha düşük.
Buna ek olarak, sadece çok daha fazlası olan özel durumlar ve tahtada vakalar değil, sadece kılavuzlar meydana geldiğinde pozitif vakaları kontrol etme eğilimi vardır. Buna ek olarak, tüm bu vakaları test etmek için bunu önceden düşünmelisiniz: Testler aynı zamanda bir tür spesifikasyon ve tartışma temeli olarak işlev görür.
Testler olmadan, kararlar genellikle bilinçli olarak alınmaz, ancak dolaylı olarak ve bu nedenle genellikle uygunsuzdur. Tabii ki, testler sadece doğru kararların garantisi değildir, ancak belirli bir yaklaşıma açıkça karar verdiği için olasılık daha yüksektir.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Neden test?
Birim, entegrasyon ve co.
Tüm testler aynı değildir, farklı test türleri vardır. Yazılımın tek tek bileşenlerini tek başına test eden SO -Called birim testleri ile başlar. Ancak bu, bir birim tarafından tam olarak ne anlaşılması gerektiği veya birimlerin sınırlarının nerede olduğu sorusunu gündeme getirir.
Çoğu durumda, bireysel işlevlerin birim olarak görülebileceği tartışılmaz olmalıdır. Fonksiyonel anlamda “saf” olduklarında, yani sonuçları sadece öğelere bağlıdır ve dışarıda, örneğin ağ erişimi veya dosya sistemi veya mevcut zaman şeklinde herhangi bir bağımlılığı olmadığında özellikle iyi test edilebilirler.
Neyse ki, bu etkiler genellikle iyi izole edilebilir, bu nedenle kodun çoğu bu testlerle kolayca korunabilir. Sınıflar bahsedilen işlevlere benzer şekilde davranırsa, bunlar da basitçe test edilir, ancak bu genellikle devlet içsel olarak devlet nedeniyle o kadar kolay olmayacaktır.
Bu nedenle bu, diğer hizmetlerin talep edildiği entegrasyon testlerine gelir, örneğin Docker kapları şeklinde başlamanız gerekir. İyi çalışır ve basitçe çoğaltılabilir, ancak her şeyden önce zaman alır.
Bir kullanıcı arayüzünü test etmek istiyorsanız, bir yandan, tek tek bileşenleri tek başına test eden bileşenlerin testleri ve diğer yandan, tam etkileşimi test eden kullanıcı arayüzünün testleri vardır. Bileşenlerin testleri genellikle web tarayıcısının dışında gerçekleştirilirken ve bu nedenle nispeten hızlı olsa da, bu kullanıcı arayüzü testleri (bilinçli olarak) için geçerli değildir, çünkü en geç çeşitli web tarayıcıları ve cihazlar için uyumluluğu test etmek istediğinizdir.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Test: Birim, Entegrasyon ve Co.
Test Geliştirme (TDD)
Prosedür ilk olarak gerçek kodu ve dolayısıyla testleri yazması açıktır. Aslında, bunu bu şekilde yapmak zorunda değilsiniz: prosedürün testine dayanan gelişme (TDD) tam tersini önerir: önce testi yazın ve bu nedenle sadece test çalışması için gerekli olanı uygular.
Test, yeni kodun gerçekten kontrol etmesinin ve tesadüfen yeşil olmadığından emin olduğundan testin başlangıçta kırmızıya dönüşmesi önemlidir. Ayrıca, her uygulama hattının bir testle motive edilmesini sağlar.
Bir sonraki teste gitmeden önce, mükemmel test örtüsü sayesinde güvenli olan kodu temizleyebilir ve optimize edebilirsiniz. Bu üç pasaj (yazma testleri, kod uygulaması, geri çekilenler, geri çekilenler) bir döngüde kendilerini tekrarladığından, burada “TDD döngüsü” veya “kırmızı-rektör” den bahsediyoruz.
Testleri ilk yazdığınızdan beri, test edilecek kodun yapısını otomatik olarak düşünürsünüz. Diğer tarafa devam ederseniz, genellikle sadece zor veya en kötü durumda test edilebilecek bir kod olduğunu öğrenin – ancak kural olarak, bu test değil, mevcut kodun yapısı nedeniyle. Testler başladığında bu sorundan kaçınılır.
Buna ek olarak, odak kodun dış şekli üzerindeki testlere odaklanır, gerçek uygulama kara bir kutudan daha fazlasıdır. Semantik arayüzleri ayarlamak için tam olarak mantıklı olan ve (yanlışlıkla) uygulama ayrıntılarına bağlı değildir. Genel olarak, kendini ve daha farkında olan TDD kodunun kullanımı oluşturulur.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Test Geliştirme (TDD)
Özel Kod Testi – Nasıl?
Ancak aslında, daha sonra testler eklemeniz gereken duruma ulaşırız. En yaygın sorunlardan biri özel kodu test etmek gibidir. Kullanılan teknolojik platforma bağlı olarak çeşitli prosedürler vardır.
Bir seçenek, özel kodu “özel” olarak ilan etmek değil, testler için az ya da çok erişime izin vermektir. Bu, örneğin “dahili” anahtar kelime ile C#'da uygulanabilir. Bunun uygulanması nispeten kolay olsa da, bunun nedeni kodun sadece inatçılığın amacı ile değiştirilmesidir.
İkinci seçenek, “özel” erişim değiştiricilerin birçok dilinde yoldaki yansımayı kullanmaktır. Avantajı, test edilecek kodun özel kalabilmesidir, ancak dezavantaj, yansıma kullanımında çok uygulanmadığınız ve bu nedenle prosedürün çok karmaşık ve hatta hantal olmasıdır.
Üçüncü ve açık ara en kötü seçenek, testleri kalıtım tarafından test edilecek koddan türetmektir. Bunun sadece dersler için çalışması dışında, oradaki tasarım seçeneklerini de sınırlar, çünkü sınıfları “mühürlü”, yani kalıtsal değil olarak işaretlemek artık mümkün değildir.
Geri adım atar ve özel kodu test etmenin mantıklı olup olmadığını sorarsanız, er ya da geç böyle olmadığı sonucuna varır: Sadece testler özel kodu kolayca çağıramadığından, diğer kod bile yapamaz. Bu, özel kodun her zaman işlevler tarafından çağrıldığı, özel olmadıkları ve dolaylı olarak bunlar yoluyla test edilebileceği anlamına gelir. Dışarıdan, dışarıdan bir uygulama detayı var.
Bazen, bu prosedürün özel kod için uygun görünmediği izlenimi olabilir, çünkü çok karmaşık ve önemlidir. Bu durumda, özel kodu bileşeninde veya modülünde dış kaynak sağlamak ve daha sonra testlerle donatmak mantıklıdır. “Birinci Sınıf” programına yönelik özel kodu kaldırın, tabiri caizse.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Özel Kod Testi – Nasıl?
Testler nasıl çalışmaz
Nasıl ilerleyeceğine bakılmaksızın, testler sadece bir stratejiye sahip olma ve neyi başarmak istediğinizi bilme varsayımı üzerinde çalışır. “TDD” deki ikinci “D”, “tasarım” için değil, “geliştirme” anlamına gelir – ve bu, kodun tasarımının önceden gerçekleşmesi gerektiği anlamına gelir. Çoğu zaman mimarinin otomatik olarak türetileceğini düşünüyorsunuz, ancak öyle değil: mimari ve yapı planlanmalıdır.
Bu, bir mimarlık revizyonu şeklinde adanmış bir komiteye ihtiyacınız olduğu anlamına gelmez, ancak anarşinin aşırı uçları ile planlanan ekonomi arasında hala sağlıklı bir sıradanlık olduğu anlamına gelir. Bu nedenle tam olarak bu dengeyi bulmak önemlidir. Mesele şu ki, sadece bir hedefiniz varsa ve öğrenmek için nesnel yönelimli bir şekilde hareket edebilirsiniz, ilk önce hipotezleri doğrulamak ve bir stratejiyi netleştirmek önemlidir. Kavramın (POC) bir testinin geliştirilmesi yardımcı olabilir.
Bu yüzden önce deneyimi elde etmek ve öğrenmek, sonra reddetmek ve bu nedenle testlerle gerçek uygulamayı geliştirmek için bir prototip geliştirir. Karşı saldırıya karşı olağan konu, bunun çok pahalı olmasıdır – sonuçta, kodu iki kez ve testler yazmanız gerekir. Bu doğrudur, ancak strateji ve nesnel olmayan prosedürün uzun vadede daha da pahalı hale geldiğini fark edemez.
Ne yazık ki, birçok alanda bir stratejinin oluşturulmadığı yanlış fikir. Bu sadece TDD için değil, aynı zamanda genel olarak çeviklik için de geçerlidir. XP, Scrum & Co.'nun kullanımı otomatik olarak iyi yapılandırılmış yazılıma yol açmaz, genellikle hiçbir stratejiniz olmadığını maskelemek için genellikle birçok kelime kolundan bahsedilir. Bu prosedür başlangıç ortamında da popülerdir.
Bununla birlikte, bir stratejiniz yoksa yazılımın (ve şirket geliştirmesinin) gelişiminin işe yaramadığı, sadece “bir şey” yapıp geri kalanın yükselmesini beklemesi özetlenebilir. Onu özen gösteren ve dikkate alanlar çok iyi.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Testler nasıl çalışmaz
Çözüm
Testler, kalite gelişiminin uzun vadeli korunması için en önemli tuğlalardan biridir. Testlerin, bir düğmeye basarak giderek daha fazla formda hızlı bir şekilde gerçekleştirilebilmesi ve dolayısıyla her türlü manuel testten çok daha güvenilir olması önemlidir. Testlerin basitçe yazılabilmesi için, kodun uygun bir yapıya sahip olması gerekir: kodun test edilmesi zordur, bu genellikle testler nedeniyle değil, aynı yapıdan kaynaklanmaktadır.
Kodu iyi yapılandırmak için, testler tarafından yönlendirilen bir geliştirme ile çalışmak tavsiye edilir, çünkü testlere dikkat etmek de harici arayüzler hakkında kasıtlı olarak düşünmeye yol açar. Bununla birlikte, deneyim elde etmek ve hedefi doğrulamak ve bir prosedür geliştirmek için prototiplerin hala gerekli olduğu göz ardı edilmemelidir. Mimari ve yapı kendi başlarına gerçekleşmez.
()