Test Odaklı Geliştirme
Test Güdümlü Geliştirme (TDD) , kodun ne yapacağını belirlemek ve doğrulamak için test senaryolarının geliştirildiği yazılım geliştirme yaklaşımıdır. Basit bir ifadeyle, önce her işlev için test senaryoları oluşturulur ve test edilir ve test başarısız olursa, testi geçmek ve kodu basit ve hatasız hale getirmek için yeni kod yazılır.
Test Odaklı Geliştirme, bir uygulamanın her küçük işlevi için testler tasarlamak ve geliştirmekle başlar. TDD, geliştiricilere yalnızca otomatik bir test başarısız olursa yeni kod yazmalarını söyler. Bu, kodun tekrarlanmasını önler. TDD'nin tam biçimi Test odaklı geliştirmedir.
TDD'nin basit kavramı, yeni kod yazmadan önce (geliştirmeden önce) başarısız testleri yazmak ve düzeltmektir. Bu, testleri geçmek için bir seferde az miktarda kod yazarken kodun tekrarlanmasını önlemeye yardımcı olur. (Testler, onları yerine getirmek için test etmemiz gereken gereksinim koşullarından başka bir şey değildir).
Test odaklı geliştirme, uygulamanın gerçek geliştirilmesinden önce otomatik test geliştirme ve çalıştırma sürecidir. Bu nedenle, TDD bazen Test First Development olarak da adlandırılır .
Bu eğitimde, hakkında daha fazla bilgi edineceksiniz:
- TDD Testi nasıl yapılır
- TDD Vs. Geleneksel Test
- Kabul TDD'si ve Geliştirici TDD'si nedir
- Agile Model Driven Development (AMDD) aracılığıyla TDD'yi ölçeklendirme
- Test Güdümlü Geliştirme (TDD) Vs. Çevik Model Odaklı Geliştirme (AMDD)
- TDD Örneği
- TDD'nin faydaları
TDD Testi nasıl yapılır
Aşağıdaki adımlar TDD testinin nasıl yapılacağını tanımlar,
- Bir test ekleyin.
- Tüm testleri çalıştırın ve yeni bir testin başarısız olup olmadığına bakın.
- Biraz kod yazın.
- Testleri ve Refactor kodunu çalıştırın.
- Tekrar et.
TDD döngüsü tanımlar
- Bir test yazın
- Çalıştırın.
- Doğru yapmak için kodu değiştirin, örneğin Refactor.
- İşlemi tekrarlayın.
TDD hakkında bazı açıklamalar:
- TDD ne "Test" ne de "Tasarım" hakkındadır.
- TDD, "testlerden bazılarını yazıp ardından testleri geçen bir sistem inşa et" anlamına gelmez.
- TDD, "çok sayıda test yapmak" anlamına gelmez.
TDD Vs. Geleneksel Test
TDD yaklaşımı, öncelikle bir spesifikasyon tekniğidir. Kaynak kodunuzun doğrulayıcı düzeyde kapsamlı bir şekilde test edilmesini sağlar.
- Geleneksel testlerde başarılı bir test bir veya daha fazla kusur bulur. TDD ile aynıdır. Bir test başarısız olduğunda, sorunu çözmeniz gerektiğini bildiğiniz için ilerleme kaydettiniz.
- TDD, sisteminizin kendisi için tanımlanan gereksinimleri gerçekten karşılamasını sağlar. Sisteminiz hakkında güveninizi geliştirmenize yardımcı olur.
- TDD'de daha fazla odak, testin düzgün çalışıp çalışmayacağını doğrulayan üretim kodudur. Geleneksel testlerde, test senaryosu tasarımına daha fazla odaklanılır. Testin, gereklilikleri yerine getirmek için uygulamanın doğru / yanlış yürütülmesini gösterip göstermeyeceği.
- TDD'de% 100 kapsama testi elde edersiniz. Geleneksel testlerden farklı olarak her bir kod satırı test edilir.
- Hem geleneksel testin hem de TDD'nin kombinasyonu, sistemin mükemmelliğinden ziyade sistemin test edilmesinin önemine yol açar.
- Çevik Modellemede (AM), "bir amaç doğrultusunda test etmelisiniz". Bir şeyi neden test ettiğinizi ve hangi seviyede test edilmesi gerektiğini bilmelisiniz.
Kabul TDD'si ve Geliştirici TDD'si nedir
İki seviye TDD vardır
- Kabul TDD (ATDD): ATDD ile tek bir kabul testi yazarsınız. Bu test, spesifikasyonun gereklerini yerine getirir veya sistemin davranışını karşılar. Bundan sonra, bu kabul testini gerçekleştirmek için yeterli üretim / işlevsellik kodu yazın. Kabul testi, sistemin genel davranışına odaklanır. ATDD, Davranış Odaklı Geliştirme (BDD) olarak da biliniyordu .
- Geliştirici TDD'si: Geliştirici TDD'si ile tek bir geliştirici testi, yani birim testi ve ardından bu testi gerçekleştirmek için yeterli üretim kodu yazarsınız. Birim testi, sistemin her küçük işlevine odaklanır. Geliştirici TDD'si basitçe TDD olarak adlandırılır .
ATDD ve TDD'nin temel amacı, çözümünüz için tam zamanında (JIT) olarak ayrıntılı, yürütülebilir gereksinimleri belirlemektir. JIT, yalnızca sistemde ihtiyaç duyulan gereksinimleri dikkate almak anlamına gelir. Yani verimliliği artırın.
Agile Model Driven Development (AMDD) aracılığıyla TDD'yi ölçeklendirme
TDD, ayrıntılı belirtim ve doğrulamada çok iyidir. Genel tasarım, sistemin kullanımı veya kullanıcı arayüzü gibi daha büyük sorunları düşünmekte başarısız oluyor. AMDD, TDD'nin yapmadığı Çevik ölçeklendirme sorunlarını ele alır.
Böylece AMDD daha büyük sorunlar için kullanıldı.
AMDD'nin yaşam döngüsü.
Modele Dayalı Geliştirmede (MDD), kaynak kodu yazılmadan önce kapsamlı modeller oluşturulur. Hangisi de çevik bir yaklaşıma sahip?
Yukarıdaki şekilde, her kutu bir geliştirme faaliyetini temsil etmektedir.
Öngörme, projenin ilk haftasında gerçekleştirilecek testlerin tahmin / tahayyülünün TDD sürecinden biridir. Öngörmenin temel amacı, sistemin kapsamını ve sistemin mimarisini belirlemektir. Başarılı bir tasavvur için üst düzey gereksinimler ve mimari modelleme yapılır.
Ayrıntılı bir yazılım / sistem tanımlamasının yapılmadığı, ancak projenin genel stratejisini tanımlayan yazılım / sistem gereksinimlerinin araştırıldığı süreçtir.
- Yineleme 0: Düşünme
İki ana alt aktivasyon vardır.
- Öngörülen ilk gereksinimler.
Sistemin üst düzey gereksinimlerini ve kapsamını belirlemek birkaç gün sürebilir. Ana odak noktası, kullanım modelini, İlk etki alanı modelini ve kullanıcı arabirimi modelini (UI) keşfetmektir.
- İlk Mimari tasavvur.
Sistemin mimarisini belirlemek de birkaç gün sürer. Proje için teknik talimatların ayarlanmasına izin verir. Ana odak noktası, teknoloji diyagramlarını, Kullanıcı Arayüzü (UI) akışını, etki alanı modellerini ve Değişiklik durumlarını keşfetmektir.
- Yineleme modellemesi:
Burada ekip, her yineleme için yapılacak işi planlamalıdır.
- Çevik süreç, her yineleme için kullanılır, yani her yineleme sırasında, yeni iş öğesi öncelikli olarak eklenecektir.
- Öncelikle daha yüksek öncelikli çalışmalar dikkate alınacaktır. Eklenen iş öğelerine herhangi bir zamanda yeniden öncelik verilebilir veya öğe yığınından kaldırılabilir.
- Ekip, her bir gereksinimi nasıl uygulayacaklarını tartışır. Modelleme bu amaçla kullanılmaktadır.
- Bu yineleme için uygulanacak her gereksinim için modelleme analizi ve tasarımı yapılır.
- Model fırtınası:
Bu aynı zamanda Tam Zamanında Modelleme olarak da bilinir.
- Burada modelleme oturumu, sorunları kağıt veya beyaz tahta üzerinde tartışan 2/3 kişilik bir ekip içerir.
- Bir ekip üyesi diğerinden kendisiyle model olmasını isteyecektir. Bu modelleme oturumu yaklaşık 5 ila 10 dakika sürecektir. Ekip üyelerinin beyaz tahta / kağıt paylaşmak için bir araya geldiği yer.
- Sorunun ana nedenini bulana kadar sorunları araştırırlar. Tam zamanında, bir ekip üyesi çözmek istediği sorunu tespit ederse, diğer ekip üyelerinden hızlı bir şekilde yardım alacaktır.
- Diğer grup üyeleri daha sonra konuyu araştırır ve sonra herkes eskisi gibi devam eder. Aynı zamanda stand-up modelleme veya müşteri QA oturumları olarak da adlandırılır.
- Test Güdümlü Geliştirme (TDD).
- Uygulama kodunuzun doğrulayıcı testini ve ayrıntılı spesifikasyonu teşvik eder.
- Hem kabul testi (ayrıntılı gereksinimler) hem de geliştirici testleri (birim testi) TDD için girdilerdir.
- TDD, kodu daha basit ve anlaşılır hale getirir. Geliştiricinin daha az belge tutmasına izin verir.
- Yorumlar.
- Bu isteğe bağlıdır. Kod incelemelerini ve model incelemelerini içerir.
- Bu, her bir yineleme için veya tüm proje için yapılabilir.
- Bu, proje için geri bildirim vermek için iyi bir seçenektir.
Test Güdümlü Geliştirme (TDD) Vs. Çevik Model Odaklı Geliştirme (AMDD)
| TDD | AMDD |
|
|
|
|
|
|
|
|
|
|
|
|
| -------------------------------------------- |
TDD Örneği
İşte bu örnekte, bir sınıf şifresi tanımlayacağız. Bu sınıf için aşağıdaki koşulları sağlamaya çalışacağız.
Parola kabulü için bir koşul:
- Parola 5 ila 10 karakter arasında olmalıdır.
İlk olarak, yukarıdaki tüm gereksinimleri karşılayan kodu yazıyoruz.
Senaryo 1 : Testi çalıştırmak için PasswordValidator () sınıfını oluşturuyoruz;
TestPassword () sınıfının üzerinde çalışacağız;
Çıkış aşağıda gösterildiği gibi GEÇTİ;
Çıktı :
Senaryo 2 : Burada TestPasswordLength () yönteminde PasswordValidator sınıfının bir örneğinin oluşturulmasına gerek olmadığını görebiliriz. Örnek, o sınıfın üyelerine (değişkenler / yöntemler) başvurmak için bir sınıf nesnesi oluşturmak anlamına gelir.
PasswordValidator pv = new PasswordValidator () sınıfını koddan kaldıracağız. İsValid () yöntemini doğrudan PasswordValidator ile çağırabiliriz . IsValid ("Abc123") . (Aşağıdaki resme bakın)
Bu yüzden aşağıdaki gibi yeniden düzenleriz (kodu değiştirin):
Senaryo 3 : Yeniden düzenleme yaptıktan sonra, çıktı başarısız durumunu gösterir (aşağıdaki resme bakın) bunun nedeni, örneği kaldırmış olmamızdır. Bu nedenle, statik olmayan yönteme (isValid ()) referans yoktur .
Bu nedenle, Boolean'ın önüne public static boolean isValid (String password) olarak "statik" kelime ekleyerek bu yöntemi değiştirmemiz gerekir. Testi geçmek için yukarıdaki hatayı kaldırmak için Sınıf PasswordValidator () yeniden düzenleniyor.
Çıktı:
PassValidator () sınıfında değişiklikler yaptıktan sonra testi çalıştırırsak, çıktı aşağıda gösterildiği gibi GEÇERLİ olacaktır.
TDD'nin Avantajları
- Erken hata bildirimi.
Geliştiriciler kodlarını test ederler ancak veritabanı dünyasında bu genellikle manuel testlerden veya tek seferlik komut dosyalarından oluşur. TDD'yi kullanarak, zaman içinde sizin ve diğer tüm geliştiricilerin istediği zaman yeniden uygulayabileceği bir otomatik testler paketi oluşturursunuz.
- Daha İyi Tasarlanmış, daha temiz ve daha genişletilebilir kod.
- Kodun nasıl kullanılacağını ve diğer modüllerle nasıl etkileşime girdiğini anlamaya yardımcı olur.
- Daha iyi tasarım kararları ve daha sürdürülebilir kod ile sonuçlanır.
- TDD, birden fazla sorumluluk içeren monolitik prosedürler yerine tek sorumluluğa sahip daha küçük kodların yazılmasına izin verir. Bu, kodun anlaşılmasını kolaylaştırır.
- TDD ayrıca kullanıcı gereksinimlerine göre testleri geçmek için yalnızca üretim kodu yazmaya zorlar.
- Refactor'a Güven
- Kodu yeniden düzenlerseniz, kodda kırılma olasılığı olabilir. Bu nedenle, bir dizi otomatik teste sahip olarak, bu molaları yayınlanmadan önce düzeltebilirsiniz. Otomatik testler kullanıldığında kesintiler bulunursa uygun uyarı verilecektir.
- TDD'yi kullanmak, minimum riskle güncellenebilen daha az hatayla daha hızlı, daha genişletilebilir kodla sonuçlanmalıdır.
- Takım çalışması için iyi
Herhangi bir ekip üyesinin yokluğunda, diğer ekip üyeleri kodu kolayca alıp üzerinde çalışabilir. Aynı zamanda bilgi paylaşımına da yardımcı olur ve böylece ekibin genel olarak daha etkili olmasını sağlar.
- Geliştiriciler İçin İyi
Geliştiricilerin TDD test senaryolarını yazmak için daha fazla zaman harcaması gerekmesine rağmen, hata ayıklama ve yeni özellikler geliştirmek çok daha az zaman alır. Daha temiz, daha az karmaşık kod yazacaksınız.
Özet:
- TDD, Test odaklı geliştirme anlamına gelir. Daha önce tasarlanmış bir testi geçmek için kodu değiştirme işlemidir.
- Test senaryosu tasarımından çok üretim koduna daha fazla vurgu yapar.
- Test odaklı geliştirme, önceden tasarlanmış bir testi geçmek için kodu değiştirme işlemidir.
- Yazılım Mühendisliğinde, bazen "Önce Test Geliştirme" olarak bilinir .
- TDD, bir kodun yeniden düzenlenmesini, yani kodun davranışını etkilemeden mevcut koda bir miktar kodun değiştirilmesini / eklenmesini içerir.
- TDD kullanıldığında, kod daha net ve anlaşılması kolay hale gelir.
Bu makale Kanchan Kulkarni tarafından hazırlanmıştır.