Test Odaklı Geliştirme (TDD) Nedir? Örnek

By: Thomas Hamilton Thomas Hamilton
Hours Güncellenmiş

Test Odaklı Geliştirme (TDD) Nedir?

Test Odaklı 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, her işlevsellik için test senaryoları önce oluşturulur ve test edilir; 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 testlerin tasarlanması ve geliştirilmesiyle başlar. TDD çerçevesi, geliştiricilere yalnızca otomatik bir testin başarısız olması durumunda yeni kod yazma talimatını verir. Bu, kodun tekrarlanmasını önler. TDD'nin tam formu Test odaklı geliştirmedir.

Test Odaklı Geliştirme

TDD'nin basit konsepti, yeni kod yazmadan önce (geliştirmeden önce) başarısız olan testleri yazmak ve düzeltmektir. Bu, testleri geçmek için bir kerede az miktarda kod yazdığımızdan kodun tekrarlanmasını önlemeye yardımcı olur. (Testler, yerine getirmek için test etmemiz gereken gereksinim koşullarından başka bir şey değildir).

Test Odaklı geliştirme, uygulamanın fiili olarak geliştirilmesinden önce otomatik test geliştirme ve çalıştırma sürecidir. Bu nedenle TDD bazen şu şekilde de adlandırılır: İlk Geliştirmeyi Test Edin.

TDD Testi nasıl yapılır?

Aşağıdaki adımlar TDD testinin nasıl gerçekleştirileceğini tanımlar:

  1. Bir test ekleyin.
  2. Tüm testleri çalıştırın ve herhangi bir yeni testin başarısız olup olmadığına bakın.
  3. Biraz kod yaz.
  4. Testleri ve Refactor kodunu çalıştırın.
  5. Tekrar et.
TDD Testi Gerçekleştirin
Test Odaklı Geliştirmenin Beş Adımı

TDD döngüsü tanımlar

  1. Bir test yaz
  2. Çalıştırmasını sağla.
  3. Doğru yapmak için kodu değiştirin, yani Refactor.
  4. İşlemi tekrarlayın.

TDD ile ilgili bazı açıklamalar:

  • TDD yaklaşımı ne “Test” ne de “Tasarım” ile ilgilidir.
  • TDD, “testlerden bazılarını yazın, ardından testleri geçen bir sistem oluşturun” anlamına gelmez.
  • TDD "çok sayıda Test yapmak" anlamına gelmez.

TDD Vs. Geleneksel Test

Test odaklı geliştirme ile geleneksel test arasındaki temel fark aşağıdadır:

TDD yaklaşımı öncelikle bir spesifikasyon tekniğidir. Kaynak kodunuzun doğrulama düzeyinde kapsamlı bir şekilde test edilmesini sağlar.

  • Geleneksel testlerde başarılı bir test bir veya daha fazla kusur bulur. TDD'nin aynısıdır. Bir test başarısız olduğunda ilerleme kaydetmişsinizdir çünkü sorunu çözmeniz gerektiğini bilirsiniz.
  • TDD, sisteminizin kendisi için tanımlanan gereksinimleri gerçekten karşılamasını sağlar. Sisteminize olan güveninizin artmasına yardımcı olur.
  • TDD'de daha çok testin düzgün çalışıp çalışmayacağını doğrulayan üretim koduna odaklanılır. 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üldüğünü gösterip göstermeyeceği.
  • TDD'de %100 kapsama testine ulaşırsınız. Geleneksel testlerden farklı olarak her kod satırı test edilir.
  • Hem geleneksel testlerin hem de TDD'nin birleşimi, sistemin mükemmelleştirilmesinden ziyade sistemin test edilmesinin önemine yol açmaktadır.
  • In Çevik Modelleme (AM), “bir amaç doğrultusunda test etmelisiniz”. Bir şeyi neden test ettiğinizi ve hangi düzeyde test edilmesi gerektiğini bilmelisiniz.

İLGİLİ MAKALELER

Kabul TDD'si ve Geliştirici TDD'si nedir?

TDD'nin iki seviyesi vardır

  1. Kabul TDD'si (ATDD): ATDD ile tek bir kabul testi yazarsınız. Bu test, spesifikasyonun gerekliliklerini yerine getirir veya sistemin davranışını karşılar. Bundan sonra, bu kabul testini karşılamaya yetecek kadar üretim/işlevsellik kodu yazın. Kabul testi sistemin genel davranışına odaklanır. ATDD aynı zamanda şu şekilde de biliniyordu: Davranış Odaklı Gelişim (BDD).
  2. Geliştirici TDD'si: Developer TDD ile tek bir geliştirici testi, yani birim testi yazarsınız ve ardından bu testi gerçekleştirmeye yetecek kadar üretim kodu yazarsınız. Birim testi sistemin her küçük işlevine odaklanır. Geliştirici TDD'ye basitçe şu ad verilir: TDD.ATDD ve TDD'nin temel amacı, çözümünüz için tam zamanında (JIT) esasına göre ayrıntılı, yürütülebilir gereksinimleri belirlemektir. JIT, yalnızca sistemde ihtiyaç duyulan gereksinimlerin dikkate alınması anlamına gelir. Yani verimliliği artırın.

Kabul TDD'si ve Geliştirici TDD'si

Çevik Model Odaklı Geliştirme (AMDD) aracılığıyla TDD'yi ölçeklendirme

TDD ayrıntılı spesifikasyon ve doğrulama konusunda çok iyidir. Genel tasarım, sistemin kullanımı veya kullanıcı arayüzü gibi daha büyük konuları düşünmekte başarısız olur. AMDD, TDD'nin çözemediği Çevik ölçeklendirme sorunlarını giderir.

Böylece AMDD daha büyük sorunlar için kullanıldı.

AMDD'nin yaşam döngüsü

AMDD'nin Yaşam Döngüsü

Model Odaklı Geliştirmede (MDD), kaynak kodu yazılmadan önce kapsamlı modeller oluşturulur. Hangisi çevik bir yaklaşıma sahip?

Yukarıdaki şekilde her kutu bir geliştirme faaliyetini temsil etmektedir.

Öngörü, projenin ilk haftasında gerçekleştirilecek testleri tahmin etme/hayal etme TDD süreçlerinden biridir. Öngörünün temel amacı sistemin kapsamını ve sistem mimarisini belirlemektir. Başarılı bir öngörü için üst düzey gereksinimler ve mimari modelleme yapılır.

Detaylı bir yazılım/sistem spesifikasyonunun yapılmadığı, projenin genel stratejisini belirleyen yazılım/sistem gereksinimlerinin araştırıldığı süreçtir.

Yineleme 0: Tasavvur Etme

İki ana alt aktivasyon vardır.

  1. İlk gereksinimlerin öngörülmesi.Sistemin üst düzey gereksinimlerinin ve kapsamının belirlenmesi birkaç gün sürebilir. Ana odak noktası, kullanım modelini, İlk etki alanı modelini ve kullanıcı arayüzü modelini (UI) keşfetmektir.
  2. Ilk Archiyapısal tasavvur. Sistemin mimarisini belirlemek de birkaç gün sürer. Proje için teknik yönlerin belirlenmesine olanak tanır. Ana odak noktası teknoloji diyagramlarını, Kullanıcı Arayüzü (UI) akışını, alan modellerini ve Değişiklik durumlarını keşfetmektir.

Yineleme modelleme

Burada ekip her yineleme için yapılacak işi planlamalıdır.

  • Her yinelemede çevik süreç kullanılır, yani her yinelemede öncelikli olarak yeni iş öğesi eklenecektir.
  • İlk önce daha yüksek öncelikli işler 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. Bu amaçla modelleme kullanılır.
  • O yinelemede 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, konuları kağıt üzerinde veya beyaz tahta üzerinde tartışan 2/3 üyeden oluşan bir ekibi içerir.
  • Bir ekip üyesi diğerinden onlarla birlikte modellik yapmasını isteyecektir. Bu modelleme oturumu yaklaşık 5 ila 10 dakika sürecektir. Ekip üyelerinin beyaz tahtayı/kağıdı 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 belirlerse, diğer ekip üyelerinden hızla yardım alacaktır.
  • Daha sonra diğer grup üyeleri konuyu araştırır ve herkes daha önce olduğu gibi devam eder. Aynı zamanda stand-up modelleme veya müşteri QA oturumları olarak da adlandırılır.

Test Odaklı Geliştirme (TDD)

  • Uygulama kodunuzun doğrulayıcı test edilmesini ve detaylı spesifikasyon oluşturulmasını sağlar.
  • 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 olanak tanır.

Yorumları

  • Bu isteğe bağlıdır. Kod incelemelerini ve model incelemelerini içerir.
  • Bu, her yineleme için veya projenin tamamı için yapılabilir.
  • Bu, projeye geri bildirim vermek için iyi bir seçenektir.

Test Odaklı Geliştirme (TDD) vs. Çevik Model Odaklı Geliştirme (AMDD)

TDD AMDD
TDD, programlama geri bildirim döngüsünü kısaltır AMDD, modelleme geri bildirim döngüsünü kısaltır.
TDD ayrıntılı spesifikasyondur AMDD daha büyük sorunlar için çalışıyor
TDD, yüksek kaliteli kodun geliştirilmesini teşvik eder AMDD, paydaşlar ve geliştiricilerle yüksek kaliteli iletişimi teşvik eder.
TDD programcılarla konuşuyor AMDD konuşuyor İş Analisti, paydaşlar ve veri profesyonelleri.
TDD görsel odaklı değil AMDD görsel odaklı
TDD'nin yazılım çalışmaları kapsamı sınırlıdır AMDD'nin paydaşları da içeren geniş bir kapsamı vardır. Ortak bir anlayışa yönelik çalışmayı içerir
Her ikisi de evrimsel gelişimi destekler ---------------

TDD Çerçeveleri

İşte en iyi test odaklı geliştirme (TDD) çerçevelerinin listesi

  1. haziran
  2. TestNG
  3. csUnit ve NUnit
  4. R spesifikasyonu

Şimdi örnek olarak Test Odaklı Geliştirmeyi öğrenelim.

TDD örneği

Bu Test Odaklı Geliştirme örneğinde, bir sınıf parolası tanımlayacağız. Bu sınıf için, aşağıdaki koşulları karşılamaya çalışacağız.

Şifre kabulü için bir koşul:

  • Şifre 5 ila 10 karakter arasında olmalıdır.

Bu TDD örneğinde öncelikle yukarıdaki tüm gereksinimleri karşılayan kodu yazıyoruz.

TDD örneği

Senaryo 1: Testi çalıştırmak için, PasswordValidator () sınıfını oluşturuyoruz;

TDD örneği

TestPassword () sınıfının üstünde çalıştıracağız;

Çıkış aşağıda gösterildiği gibi BAŞARILDI;

Çıktı:

TDD örneği

Senaryo 2: Burada TestPasswordLength () yönteminde, PasswordValidator sınıfının bir örneğini oluşturmaya gerek olmadığını görebiliriz. Örnek oluşturmak anlamına gelir nesne o sınıfın üyelerine (değişkenler/yöntemler) atıfta bulunmak için sınıfın.

TDD örneği

CodeValidator pv = new PasswordValidator () sınıfını koddan kaldıracağız. arayabiliriz Geçerlidir () doğrudan yöntem Şifre Doğrulayıcı. Geçerlidir (“Abc123”). (Aşağıdaki resme bakın)

Bu yüzden aşağıdaki gibi Refactor (kodu değiştiriyoruz) yapıyoruz:

TDD örneği

Senaryo 3: Yeniden düzenlemeden sonra çıktı başarısız durumunu gösteriyor (aşağıdaki resme bakın) bunun nedeni örneği kaldırmış olmamızdır. Bu nedenle statik olmayan yönteme bir referans yoktur Geçerlidir ().

TDD örneği

Bu yüzden Boolean'ın önüne public static boolean isValid (String şifresi) olarak "statik" kelimesini ekleyerek bu yöntemi değiştirmemiz gerekiyor. Testi geçmek için yukarıdaki hatayı kaldırmak üzere Class PasswordValidator () yeniden düzenleniyor.

TDD örneği

Çıktı:

PassValidator () sınıfında değişiklik yaptıktan sonra testi çalıştırırsak çıktı aşağıda gösterildiği gibi PASSED olacaktır.

TDD örneği

TDD'nin Avantajları

Yazılım Mühendisliğinde Test Odaklı Geliştirmenin başlıca avantajları şunlardır:

Erken hata bildirimi.

  • Geliştiriciler kodlarını test eder 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 geliştiricilerin istediğiniz zaman yeniden çalıştırabileceği bir dizi otomatik test 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 kararı ve daha sürdürülebilir kodla sonuçlanır.
  • TDD, birden fazla sorumluluğa sahip monolitik prosedürler yerine tek sorumluluğa sahip daha küçük kodların yazılmasına olanak tanır. 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 kodunu yazmaya zorlar.

Refactor'a Güven

  • Kodu yeniden düzenlerseniz, kodda kırılma olasılıkları olabilir. Yani bir dizi otomatik teste sahip olarak, bu kesintileri yayınlanmadan önce düzeltebilirsiniz. Otomatik testler kullanıldığında kesintiler bulunursa uygun uyarı verilecektir.
  • TDD'yi kullanmak, daha az hatayla ve minimum riskle güncellenebilen daha hızlı, daha genişletilebilir kodla sonuçlanacaktır.

Takım çalışması için iyi

  • Herhangi bir ekip üyesinin yokluğunda, diğer ekip üyeleri kodu kolaylıkla 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ştirme ç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.
  • TDD anlamı: Daha önce tasarlanmış bir testi geçmek için kodu değiştirme işlemidir.
  • Test senaryosu tasarımından ziyade üretim koduna daha fazla vurgu yapılır.
  • Test odaklı geliştirme, daha önce tasarlanmış bir testi geçmek için kodu değiştirme sürecidir.
  • In Yazılım Mühendisliği, Bazen şu şekilde bilinir: “İlk Geliştirmeyi Test Edin.”
  • TDD testi, kodun yeniden düzenlenmesini, yani kodun davranışını etkilemeden mevcut koda bir miktar kodun değiştirilmesini/eklenmesini içerir.
  • TDD programlama kullanıldığında kod daha net ve anlaşılması kolay hale gelir.

Beğenebilirsin: