Yazma testi: temel bilgiler
Test, yüksek kaliteli ve sürdürülebilir yazılım geliştirmek için temel bir unsurdur. Peki testler tam olarak neden bu kadar önemlidir, faydaları nelerdir ve kullanılma sebepleri nelerdir? Yoksa elle test etmek mümkün değil mi?
Testlerin alaka düzeyi sorusuna sık sık alıntılanan bir yanıt, bunları kullanarak yazılımınızın amaçlandığı gibi çalışmasını sağlayabileceğinizdir. Bu prensipte yanlış değil, aslında ikincildir.
Daha da önemlisi test, bugün veya yarın yapılabileceği için istenmeyen değişikliklere karşı bir güvenlik ağı görevi görür. Yol boyunca, zaten çalışmakta olan bir şeyin fark edilmeden kırılma riski olmadan kodunuzu genişletmenize ve bütünleştirmenize olanak tanırlar. Bu nedenle uzun vadeli istikrar ve kaliteye katkıda bulunurlar.
Testleri otomatik olarak çalıştırabilmek önemlidir, çünkü ancak o zaman kod yeniden üretilebilir, deterministik ve hızlı bir şekilde test edilebilir. Teorik olarak, manuel testler de düşünülebilir, ancak bu durumda bahsedilen üç husus artık verilmemektedir. Tabii ki, başlangıçta test yazmak çok zaman alıyor, ancak özellikle uzun vadede çaba, manuel testlerden önemli ölçüde daha az ve aynı zamanda çok daha güvenilir.
Ayrıca, manuel test sırasında, genellikle çok daha fazla olan özel durumları ve uç durumları değil, yalnızca pozitif durumları kontrol etme eğilimindeyiz. Ayrıca, tüm bu durumları test edebilmek için önce bunları düşünmek gerekir: testler aynı zamanda bir tanımlama ve tartışma için bir temel görevi görür.
Test yapılmadan, kararlar genellikle bilinçli olarak değil, dolaylı olarak verilir ve bu nedenle genellikle uygunsuzdur. Elbette, testler sadece doğru kararların garantisi değildir, ancak belirli bir prosedüre açıkça karar verdiğiniz için olasılık daha yüksektir.
Önerilen editoryal içerik
İzninizle, buraya harici bir YouTube videosu (Google Ireland Limited) yüklenecek.
Her zaman YouTube videoları yükleyin
YouTube videosunu şimdi yükleyin
Neden testler?
Unity, Entegrasyon ve Co.
Tüm testler eşit yaratılmamıştır, farklı test türleri vardır. Bireysel yazılım bileşenlerini birbirinden ayrı olarak test eden birim testleri ile başlar. Ancak bu, “birimler” ile tam olarak ne kastedildiği veya birimlerin sınırlamalarının nerede olduğu sorusunu gündeme getirir.
Çoğu durumda, bireysel işlevlerin bir birim olarak görülebileceği tartışılmaz. İşlevsel anlamda “saf” iseler, yani sonuçları yalnızca girdilere bağlıysa ve örneğin ağ veya dosya sistemi erişimi veya şimdiki zaman gibi hiçbir dış bağımlılığı yoksa, özellikle iyi test edilebilirler.
Neyse ki, bu tür etkiler genellikle iyi bir şekilde izole edilebilir, bu nedenle birçok kod bu tür testlerle iyi bir şekilde korunabilir. Sınıflar belirtilen işlevlere benzer şekilde davranırsa, kolayca test edilebilirler, ancak sınıfların doğasında bulunan durum nedeniyle çoğu zaman bu o kadar kolay olmayacaktır.
Bu daha sonra, örneğin bir Docker kabı biçiminde başlatmanız gereken, genellikle başka hizmetlerin gerekli olduğu entegrasyon testlerine yol açar. İyi çalışır ve yeniden üretilmesi kolaydır, ancak her şeyden önce zamana mal olur.
Bir kullanıcı arayüzünü test etmek istiyorsanız, tek tek bileşenleri ayrı ayrı test eden bileşen testleri ve tüm etkileşimi test eden kullanıcı arayüzü testleri vardır. Bileşen testleri genellikle web tarayıcısının dışında yapılır ve bu nedenle nispeten hızlıdır, ancak bu (kasıtlı olarak) UI testleri için geçerli değildir, çünkü burası en geç farklı web tarayıcıları ve cihazlarla uyumluluğu test etmek istediğiniz yerdir.
Önerilen editoryal içerik
İzninizle, buraya harici bir YouTube videosu (Google Ireland Limited) yüklenecek.
Her zaman YouTube videoları yükleyin
YouTube videosunu şimdi yükleyin
Test: Unity, Integration & Co.
Test Odaklı Geliştirme (TDD)
Bariz yaklaşım, önce gerçek kodu ve ardından testleri yazmaktır. Aslında, bunu bu şekilde yapmak zorunda değilsiniz: Test Odaklı Geliştirme (TDD) yaklaşımı tam tersini önerir: önce testi yazın ve ardından yalnızca testin çalışması için gerekli olanı uygulayın.
Önce testin kırmızıya dönmesi önemlidir, çünkü bu sırada testin aslında yeni kodu kontrol ettiğinden ve yanlışlıkla yeşile dönmediğinden emin olursunuz. Ayrıca, her uygulama satırının bir test tarafından motive edilmesini sağlar.
Bir sonraki teste geçmeden önce, mükemmel test kapsamı sayesinde risk almadan mümkün olan kodu temizleyebilir ve optimize edebilirsiniz. Bu üç adım (test yazma, kod uygulama, temizleme) bir döngüde tekrarlandığından, buna “TDD döngüsü” veya “kırmızı-yeşil yeniden düzenleme” de denir.
Önce testler yazarak, test edilecek kodun yapısını otomatik olarak düşünürsünüz. Tersini yaparsanız, genellikle zor veya en kötü durumda test edilmesi imkansız olan kodlar olduğunu görürsünüz – bu genellikle test nedeniyle değil, mevcut kodun yapısından kaynaklanır. Testleri en başa koyarak bu sorunun önüne geçilebilir.
Ayrıca, teste odaklanma nedeniyle, kodun dış biçimine daha fazla odaklanılır, gerçek uygulama daha çok bir kara kutu gibidir. Semantik arayüzleri tanımlamanın ve uygulama ayrıntılarına (yanlışlıkla) bağımlı hale gelmemenin tam olarak anlamı budur. Genel olarak, TDD kodunu kullanmak daha düşünceli ve bilinçli bir gelişim sağlar.
Önerilen editoryal içerik
İzninizle, buraya harici bir YouTube videosu (Google Ireland Limited) yüklenecek.
Her zaman YouTube videoları yükleyin
YouTube videosunu şimdi yükleyin
Test Odaklı Geliştirme (TDD)
Özel kodu test edin – nasıl?
Ancak gerçekte, kendinizi genellikle daha sonra mevcut koda testler eklemeniz gereken bir durumda bulursunuz. O zaman en yaygın sorunlardan biri, özel kodun nasıl test edileceğidir. Kullanılan teknoloji platformuna bağlı olarak bunu yapmanın birkaç yolu vardır.
Seçeneklerden biri, özel kodu “özel” olarak bildirmek değil, test için az ya da çok belirli erişime izin vermektir. Bu, örneğin “internal” anahtar kelimesiyle C#’ta uygulanabilir. Bunun uygulanması nispeten kolay olsa da, yalnızca test edilebilirlik amacıyla kodda değişiklik yapılmasını gerektirir.
İkinci seçenek yansıma kullanmaktır – bu şekilde birçok dilde “özel” erişim değiştiricisini geçersiz kılabilirsiniz. Avantajı, test edilecek kodun özel kalabilmesidir, ancak dezavantajı, yansıma kullanımında çok deneyimli olmamanız ve bu nedenle prosedürün çok zaman alıcı ve kesinlikle külfetli olmasıdır.
Üçüncü ve açık ara en kötü seçenek, testleri kalıtım yoluyla test edilen koddan çıkarmaktır. Bunun zaten sadece sınıflar için geçerli olmasının yanı sıra, örneğin sınıfları “mühürlü”, yani kalıtsal olmayan olarak işaretlemek artık mümkün olmadığından, oradaki tasarım seçeneklerini de sınırlar.
Bir adım geri gider ve özel kodu test etmenin mantıklı olup olmadığını merak ederseniz, er ya da geç bunun mantıklı olmadığı sonucuna varırsınız: ne özel kodu kolayca çağırabilen testler ne de diğer kodlar. . Bu, özel kodun her zaman özel olmayan işlevler tarafından çağrıldığı ve bunlar aracılığıyla dolaylı olarak test edilebileceği anlamına gelir. Dışarıdan bakıldığında bunun private kod olması nihayetinde bir uygulama detayıdır.
Bazen bu yaklaşımın çok karmaşık ve önemli olan özel kod için uygun olmadığı düşünülebilir. Bu durumda, özel kodu ayrı bir bileşen veya modüle harici hale getirmek ve ardından onu testlerle donatmak mantıklıdır. Biri, tabiri caizse, özel kodu “birinci sınıf” koda yükseltir.
Önerilen editoryal içerik
İzninizle, buraya harici bir YouTube videosu (Google Ireland Limited) yüklenecek.
Her zaman YouTube videoları yükleyin
YouTube videosunu şimdi yükleyin
Özel kodu test edin – nasıl?
testler nasıl çalışmıyor
Nasıl yaparsanız yapın, test yalnızca bir stratejiniz varsa ve neyi başarmak istediğinizi biliyorsanız işe yarar. “TDD”deki ikinci “D”, “Tasarım” değil, “Geliştirme” anlamına gelir ve bu, kodun tasarımının önce gerçekleşmiş olması gerektiği anlamına gelir. Sık sık mimarinin otomatik olarak ortaya çıkacağını duyuyoruz, ancak durum böyle değil: mimari ve yapı tasarlanmalıdır.
Bu, bir mimari inceleme kurulu şeklinde özel bir organa ihtiyaç olduğu anlamına gelmez, ancak anarşinin uç noktaları ile planlı bir ekonomi arasında hala sağlıklı bir orta yol vardır. Bu nedenle tam olarak bu dengeyi bulmak önemlidir. Mesele şu ki, ancak bir hedefiniz olduğunda hedef odaklı olabilirsiniz ve onu keşfetmek için önce varsayımları doğrulamanız ve bir stratejiyi netleştirmeniz gerekir. Bir kavram kanıtı (PoC) geliştirmek burada yardımcı olabilir.
Yani önce deneyim kazanmak ve öğrenmek için bir prototip geliştirirsiniz, sonra onu hurdaya çıkarırsınız ve ardından test ederek gerçek uygulamayı geliştirirsiniz. Olağan karşı argüman, bunun çok pahalı olduğudur: Sonuçta, kodu iki kez yazmanız ve testler yapmanız gerekir. Bu doğru olmakla birlikte, stratejisiz ve hedefsiz ilerlemenin uzun vadede daha da maliyetli olacağının farkında değil.
Ne yazık ki, bir stratejiye ihtiyacınız olmadığı yanılgısı birçok alanda kendini kabul ettirmiştir. Bu sadece TDD için değil, genel olarak çeviklik için de geçerlidir. XP, Scrum & Co. kullanımı bile otomatik olarak iyi yapılandırılmış bir yazılıma yol açmaz, genellikle stratejiniz olmadığı gerçeğini gizlemek için burada yalnızca çok sayıda boş cümleden bahsedilir. Bu yaklaşım, önyükleme ortamında da popülerdir.
Ancak sonuç olarak, bir stratejiniz yoksa yazılım geliştirme (ve bu konuda iş geliştirme) işe yaramaz, sadece “bir şeyler” yapar ve geri kalanının yerine oturmasını beklersiniz. Kalbinize alır ve dikkate alırsanız, zaten birçok şeyi doğru yapıyorsunuz.
Önerilen editoryal içerik
İzninizle, buraya harici bir YouTube videosu (Google Ireland Limited) yüklenecek.
Her zaman YouTube videoları yükleyin
YouTube videosunu şimdi yükleyin
testler nasıl çalışmıyor
Çözüm
Test, uzun vadede yazılım geliştirmede kaliteyi korumak için en önemli yapı taşlarından biridir. Burada özellikle ilgili olan, testlerin her zaman bir düğmeye basarak hızlı ve aynı biçimde gerçekleştirilebilmesi ve bu nedenle herhangi bir manuel test türünden çok daha güvenilir olmasıdır. Bununla birlikte, testlerin yazılmasının kolay olması için, kodun yeterli bir yapıya sahip olması gerekir: kodun test edilmesi zorsa, bunun nedeni genellikle testlerden değil, bu yapıdır.
Kodunuzu iyi bir şekilde yapılandırmak için test odaklı geliştirme ile çalışmak mantıklıdır, çünkü teste odaklanmak aynı zamanda bilinçli olarak harici arayüzler hakkında düşünmek anlamına gelir. Bununla birlikte, deneyim kazanmak ve hedefi doğrulamak ve bir prosedür geliştirmek için prototiplere hala ihtiyaç duyulduğu unutulmamalıdır. Mimari ve yapı kendiliğinden ortaya çıkmaz.
()
Haberin Sonu