Otomatikleştirilmiş test nedir?
Bu ünitede otomatik testin avantajları ve gerçekleştirebileceğiniz test türleri hakkında bilgi edineceksiniz. Ayrıca iyi bir testin ne olduğunu öğrenecek ve kullanabileceğiniz bazı test araçlarıyla tanıştırılacaksınız.
Otomatikleştirilmiş test nedir?
Otomatik test , kodunuzu yürütmek ve gerçek sonuçları beklediğiniz sonuçlarla karşılaştırmak için yazılım kullanır. Bunu, bir insanın genellikle bir test planındaki yönergeleri izleyerek yazılımın beklendiği gibi çalıştığını doğruladığı keşif veya el ile test etme ile karşılaştırın.
El ile test yapmanın avantajları vardır. Ancak kod tabanınızın boyutu büyüdükçe, tüm özellikleri el ile test etme (uç durumlar dahil) yinelenen, sıkıcı ve hataya açık hale gelebilir. Otomatik test, bu yükün bir kısmını ortadan kaldırmaya yardımcı olabilir ve el ile test edenlerin en iyi yaptıkları şeye odaklanmasını sağlayabilir: kullanıcılarınızın yazılımınızla olumlu bir deneyim yaşamasını sağlar.
Test piramidi
Otomatikleştirilmiş testi düşündüğümüzde, testleri katmanlara ayırmak yaygın bir durum. Mike Cohn, Agile ile Başarılı olma kitabında test piramidi olarak bilinen bu kavramı önerir.
Bu, Cohn modelinin basit bir sürümü olsa da bu kavram, çalışmanızın büyük bölümünü yazılımlarınızın temel düzeylerini (piramitteki açıklama balonu 1) (işlevler, sınıflar ve yöntemler gibi) doğrulayan testler yazmaya odaklamanızı göstermektedir. Kullanıcı arabirimi (UI) katmanı (piramitteki belirtme çizgisi 2) gibi özellikler birleştirildiğinden aşamalı olarak daha az çabaya odaklanırsınız. Fikir şudur: Her alt düzey bileşenin yalıtımda beklendiği gibi çalıştığını doğrulayabilirseniz, yüksek düzeylerdeki testlerin beklenen sonucu elde etmek için yalnızca birden çok bileşenin birlikte çalıştığını doğrulaması gerekir.
Testleri ne zaman yazmam gerekir?
Yanıt temel olarak gereksinimlerinize ve test yazma deneyiminize bağlıdır.
Önceden yazıp dağıtmış olduğunuz kod için test eklemeye başlamak için hiçbir zaman çok geç değildir. Bu durum özellikle test ekibinizin en çok çaba harcamasını gerektiren veya bozan özellikler için geçerlidir.
Testi sürekli tümleştirme ve sürekli teslim işlem hatlarıyla ilişkilendirdiğinizde, duyacağınız iki kavram sürekli test ve sola kaydırmadır.
Sürekli test, her değişiklik işlem hattında ilerledikçe testlerin geliştirme sürecinin erken aşamalarında çalıştırılıyor olduğu anlamına gelir. Sola kaydırmak, geliştirme sürecinin önceki bölümlerinde yazılım kalitesini ve test etmeyi göz önünde bulundurmak anlamına gelir.
Örneğin, geliştiriciler genellikle özelliklerini geliştirirken test çalışmaları ekler ve değişikliği işlem hattına göndermeden önce test paketinin tamamını çalıştırır. Bu yaklaşım, derledikleri özelliğin beklendiği gibi davranmasını ve mevcut özellikleri bozmamasını sağlamaya yardımcı olur.
Microsoft Bulut Danışmanı Abel Wang'ın DevOps planınızda kaliteyi nasıl koruyacağınızı açıkladığı kısa bir video.
Abel'a sorun
Sola kaydırma, özellik için herhangi bir kod yazılmadan önce bile test edicilerin tasarım sürecine dahil olmasını gerektirir. Bunu, test ekibine yalnızca yazılım tasarlanıp yazıldıktan sonra test etmek için yeni özellikler sunulan "iletim" modeliyle karşılaştırın. İşlemin sonlarında bulunan bir hata, ekibin teslim zamanlamasını etkileyebilir ve hatalar geliştiricinin özelliği ilk oluşturmasının ardından haftalar, hatta aylar sonra bulunabilir.
Denge
Otomatik test ile bir denge vardır. Otomatikleştirilmiş test, test edenlerin zamanlarını son kullanıcı deneyimini doğrulamaya odaklanmasına olanak sağlasa da, geliştiricilerin test kodlarını yazmak ve korumak için daha fazla zaman ayırmaları gerekebilir.
Ancak otomatik testin amacı, test edenlerin yalnızca beklendiği gibi çalışması kanıtlanmış en yüksek kaliteli kodu almasını sağlamaya yardımcı olmaktır. Bu nedenle geliştiriciler, başlangıçta dikkate almadıkları bir uç durum nedeniyle daha az hatayı işlemek veya kod yeniden yazmaktan kaçınarak zamanlarının bir kısmını geri alabilir.
Eklenen avantajlar
Belgeler ve kodunuzu daha kolay yeniden düzenleme olanağı, otomatik testin iki ek avantajıdır.
Belgeler
El ile test planları, yazılımın nasıl davranması gerektiği ve belirli özelliklerin neden mevcut olduğu konusunda bir belge türü olarak görev yapabilir.
Otomatikleştirilmiş testler aynı amaca hizmet edebilir. Otomatik test kodu genellikle insan tarafından okunabilir bir biçim kullanır. Sağladığınız giriş kümesi, kullanıcılarınızın girebileceği değerleri temsil eder. İlişkili her çıkış, kullanıcılarınızın beklemesi gereken sonucu belirtir.
Aslında, birçok geliştirici yeni bir özellik uygulamadan önce test kodunu yazarak test temelli geliştirme (TDD) yöntemini izler. Fikir, genellikle belirtimler olarak adlandırılan ve başlangıçta başarısız olan bir dizi test yazmaktır. Ardından geliştirici, tüm testler geçene kadar özelliği uygulamak için artımlı olarak kod yazar. Belirtimler yalnızca gereksinimleri belgelemiyor, aynı zamanda TDD işlemi özelliği uygulamak için yalnızca gerekli kod miktarının yazılmasını sağlamaya yardımcı olur.
Yeniden Düzenle
Belirli bölümlerin daha hızlı çalışmasını sağlamak için yeniden düzenlemek istediğiniz büyük bir kod tabanınız olduğunu varsayalım. Yeniden düzenleme çabalarınızın uygulamanızın bazı bölümlerinin bozulmasına neden olmayacağından nasıl emin olursunuz?
Otomatikleştirilmiş testler bir sözleşme türü görevi görür. Yani, girişleri ve beklenen sonuçları belirtirsiniz. Bir dizi geçiş testine sahip olduğunuzda kodunuzu deneme ve yeniden düzenleme konusunda daha iyi bir deneyim elde edebilirsiniz. Bir değişiklik yaptığınızda tek yapmanız gereken testlerinizi çalıştırmak ve geçmeye devam ettiklerini doğrulamaktır. Yeniden düzenleme hedeflerinize ulaşmanızın ardından, değişikliklerinizi derleme işlem hattına göndererek herkesin avantajlı olmasını sağlayabilirsiniz ancak hataya neden olabilecek bir risk daha düşüktür.
Ne tür otomatikleştirilmiş test vardır?
Birçok otomatik test türü vardır. Her test ayrı bir amaca hizmet eder. Örneğin, bir yazılım parçasına veya özelliklerinden birine yalnızca yetkili kullanıcıların erişebildiğini doğrulamaya yardımcı olmak için güvenlik testleri çalıştırabilirsiniz.
Sürekli tümleştirmeden ve derleme işlem hattından söz ettiğimizde genellikle geliştirme testlerine başvururuz. Geliştirme testi, uygulamayı bir test veya üretim ortamına dağıtmadan önce çalıştırabileceğiniz testleri ifade eder.
Örneğin, statik kod analizinin bir biçimi olan lint testi, kaynağınızın ekibinizin stil kılavuzuna uygun olup olmadığını belirlemek için kaynak kodunuzu denetler. Tutarlı bir şekilde biçimlendirilmiş kodlar herkesin okuması ve bakımını yapmak için daha kolaydır.
Bu modülde birim testi ve kod kapsamı testi ile çalışacaksınız.
Birim testi, tek bir işlev veya yöntem gibi programınızın veya kitaplığınızın en temel bileşenlerini doğrular. Beklenen sonuçlarla birlikte bir veya daha fazla giriş belirtirsiniz. Test çalıştırıcısı her testi gerçekleştirir ve gerçek ve beklenen sonuçların eşleşip eşleşmediğini denetler.
Örneğin, bölme içeren bir aritmetik işlem gerçekleştiren bir işleviniz olduğunu varsayalım. Kullanıcılarınızın 0 ve -1 gibi kenar örneği değerleriyle birlikte girmesini beklediğiniz birkaç değer belirtebilirsiniz. Belirli bir giriş hata veya özel durum oluşturursa, işlevin aynı hatayı ürettiğini doğrulayabilirsiniz.
Kod kapsamı testi, birim testlerinizin kapsamındaki kodunuzun yüzdesini hesaplar. Kod kapsamı testi, bir işlevin ele alındığından emin olmak için kodunuzda koşullu dallar içerebilir.
Kod kapsamı yüzdeniz ne kadar büyükse, kodda daha sonra tam olarak test edilmemiş bir hata bulmayacağınızdan o kadar emin olabilirsiniz. Yüzde 100 kod kapsamına ulaşmanız gerekmez. Aslında, başladığınızda büyük olasılıkla düşük bir yüzdeye sahip olduğunuzu fark edersiniz, ancak bu size sorunlu veya sık kullanılan kodu kapsayan ek testler ekleyebileceğiniz bir başlangıç noktası sağlar.
Birim testlerini yalıtılmış tutma
Birim testi hakkında bilgi edinirken sahteler, saplamalar ve bağımlılık ekleme gibi terimleri duyabilirsiniz.
Bir birim testinin birden çok bileşenin nasıl etkileşim kurduğunu değil tek bir işlevi veya yöntemi doğrulaması gerektiğini hatırlayın. Ancak bir veritabanını veya web sunucusunu çağıran bir işleviniz varsa bunu nasıl işlersiniz?
Dış hizmete yapılan çağrı yalıtımı kesmekle kalmaz, aynı zamanda işleri yavaşlatabilir. Veritabanı veya web sunucusu kapanırsa veya başka bir şekilde kullanılamıyorsa, çağrı test çalıştırmanızı da kesintiye uğratabilir.
Sahte ve bağımlılık ekleme gibi teknikleri kullanarak bu dış işlevi taklit eden bileşenler oluşturabilirsiniz. Bu modülün ilerleyen bölümlerinde bir örnek alacaksınız.
Daha sonra, uygulamanızın gerçek bir veritabanı veya web sunucusuyla düzgün çalıştığını doğrulamak için tümleştirme testleri çalıştırabilirsiniz.
İyi bir test yapan nedir?
Kendi testlerinizi yazma ve başkaları tarafından yazılan testleri okuma deneyimi kazandıkça iyi bir testi daha iyi belirleyebilirsiniz. Başlamaya yönelik bazı yönergeler şunlardır:
- Test etmek için test etmeyin: Testleriniz, çapraz geçiş yapılacak bir denetim listesi öğesi olmanın ötesinde bir amaca hizmet etmelidir. Kritik kodunuzun amaçlandığı gibi çalıştığını ve mevcut işlevselliği bozmadığını doğrulayan testler yazın.
- Testlerinizi kısa tutun: Testler, özellikle geliştirme ve derleme aşamalarında gerçekleşen testlerin mümkün olan en kısa sürede bitmesi gerekir. Her değişiklik işlem hattında ilerlerken testler çalıştırıldığında performans sorunu olmasını istemezsiniz.
- Testlerinizin yinelenebilir olduğundan emin olun: Test çalıştırmaları, bilgisayarınızda, iş arkadaşınızın bilgisayarında veya derleme işlem hattında her seferinde aynı sonuçları üretmelidir.
- Testlerinizin odaklanmasını sağlayın: Yaygın bir yanılgı, testlerin başkaları tarafından yazılan kodu kapsaması gerektiğidir. Normalde testleriniz yalnızca kodunuzu kapsamalıdır. Örneğin, projenizde açık kaynak grafik kitaplığı kullanıyorsanız, bu kitaplığı test etmeniz gerekmez.
- Doğru ayrıntı düzeyini seçin: Örneğin, birim testi yapıyorsanız, tek bir test birden çok işlevi veya yöntemi birleştirmemeli veya test etmemelidir. Her işlevi ayrı ayrı test edin ve daha sonra birden çok bileşenin düzgün etkileşimde bulunduğunu doğrulayan tümleştirme testleri yazın.
Hangi tür test araçları kullanılabilir?
Kullandığınız test araçları, oluşturduğunuz uygulamanın türüne ve gerçekleştirmek istediğiniz test türüne bağlıdır. Örneğin, Birçok web tarayıcısı ve işletim sistemi türü üzerinde kullanıcı arabirimi testi gerçekleştirmek için Selenium kullanabilirsiniz.
Uygulamanızın hangi dilde yazıldığından bağımsız olarak, kullanabileceğiniz birçok test aracı vardır.
Örneğin, Java uygulamaları için lint testi yapmak için Checkstyle'ı ve birim testi gerçekleştirmek için JUnit'i seçebilirsiniz.
Bu modülde, .NET topluluğunda popüler olduğundan birim testi için NUnit kullanacağız.