Yazılım Geliştirme Sürecinde Test: TDD, ATDD ve BDD Arasındaki Farklar

Sizin için en uygun test stratejisinin hangisi olduğuna karar verin?

Test Nedir?

Test, proje gelişimi esnasında çoğu zaman müşterinin beklentisi dışındadır. Oysa ki projenin başarılı bir şekilde tamamlanması için test çok önemlidir. Yazılım geliştiricilere ayrılan birim test süresi çoğu zaman yeterli olmamaktadır.

Bir test stratejisi, harcanan zaman ile alınan faydalar arasında bir denge sağlayan dikkatlice düşünülmüş bir uygulama stratejisi olmalıdır.

TDD, ATDD ve BDD gibi test stratejilerini anlamak ve yerinde kullanmak için bu stratejilere bir göz atalım..

Test Odaklı Geliştirme (Test-Driven Development)

Test odaklı geliştirme, kodu test etmek ve bağımlılıkları koddan ayırmak için Birim Testleri yazarak yapılır.

Bu stratejide önemli olan kod yazılmadan önce testleri yazmaktır.

TDD süreci aşağıdaki adımları içerir;

• Belirtilen gereksinimlere göre yazılım geliştirici bir test senaryosu yazar
• Bu testler gerçekleştirilir ve bir özelliğin geliştirilmesinden önce yazıldığı için başarısız olması beklenir
• Geliştirme ekibi tarafından testin başarıyla geçmesi için kodlama yapılır
• Bütün testlerin başarılı olması sağlanır
• Kod tekrar gözden geçirilir ve düzenlenir. İyileştirme veya temizleme yapılır

Burada bahsedilen kodu düzenleme süreci, kodun ana işlevini veya davranışını değiştirmeden sadece kodu iyileştirme veya temizleme sürecini ifade eder. Kod hata almayana kadar bu değiştirme ve düzenleme devam eder.

Aslında TDD geliştirme süreci, agile süreçler ile hayatımıza girdi. Daha önce waterfall modeli yönetim sürecinde aşamalar şu şekildeydi;

• Tasarımı yap
• Geliştirmeyi yaz
• Testi yap

TDD sonrası agile aşamasında ise kodlama sürecinden önce test yazma aşaması eklenmiş oldu. TDD ile aşamalar ise şu şekilde olacaktır;

• Tasarımı yap
• Testi yaz
• Geliştirmeyi yaz
• Testi yap

Test Odaklı Geliştirme süreci, kod yazılmadan önce Birim Testlerinin yazılmasını içerir. Yazılımcı için bu süreç, bir problemi çözmek için belirli bir algoritma yazılmadan önce kodun analizinin yapılmış olması ve davranışını bilmesi gerektiği anlamına gelir. Bu süreç ile test yazılırken, bir işlevin çıktısı olan bazı koşullardan geçeceği anlamına gelir.

Ayrıca, söz konusu kodun tüm satırlarını kapsayacak şekilde test yazılması gerektiği anlamına gelir. Bu da, kod kapsamımızın yazdığımız tüm kod satırlarının yüksek bir yüzdesi olduğundan emin olmamız gerekliliğini doğurur.

TDD süreci, bir yazılım geliştiricisinin kodu yeniden düzenlemesine ve kodun verimliliğini en üst düzeye çıkarmasına engel olmaz. Review sürecinin bir parçası olarak TDD bu sürece uygun oluyor ve muhtemelen ilerledikçe kendi kodunuzu gözden geçirmiş oluyorsunuz. Testinizin kalitesi ile kodunuzun uygun kalitede olup olmadığını da netleştirmiş olabilirsiniz. TDD ile metodoloji veya yöntem olmadan test üretildiğinden, geliştirme sonrasında daha iyi bir kod review süreci için faydalı olacak bir süreci sağlamış olursunuz.

TDD kullanmanın birkaç büyük avantajı vardır. Bunlar;

• Bakım yükünü azaltmaktadır
• Hatalar kolayca görülebilmekte ve bunları düzeltmek için hemen geri bildirim alınmaktadır
• Daha temiz ve daha iyi tasarımların geliştirilmesini teşvik eder
• Kod yazıldığında test edilebilir olmaktadır
• Yazılım geliştiriciler, TDD sürecine alıştıkça üretkenlikleri artmaktadır
• Kod, testler tarafından yönlendirildiği için anlaşılması kolay olmaktadır. Yani herhangi bir ekip üyesinin yokluğunda diğer ekip üyelerinin kod üzerinde kolayca çalışmasını sağlar. Bu sayede ekipteki bilgi paylaşımını ve işbirliğini teşvik eder
• Geliştiriciye uygulamanın geniş mimarisini kolayca değiştirmesi için güven verir

Davranış Odaklı Geliştirme (Behavior-Driven Development)

Davranış Odaklı Geliştirme, Test Odaklı Geliştirmenin bir türevidir. Ancak testler, esas olarak sistem davranışına dayanmaktadır.

Test Odaklı Geliştirme bazı koşulları ileri sürerken, Davranış Odaklı Geliştirme sistemin davranışını açıklamak için gerçek gereksinimlerin gerçek zamanlı örnekleri kullanılarak düz metin olarak yazılır. Bu sayede yazılan bu metinler ile uygulamanın güncel bir dokümanının oluşmasını sağlamış olursunuz.

Test senaryolarını yazarken Given, When, Then gibi komutlar kullanılır.

Örnekleyecek olursak;

• Given: Belirli bir senaryo yazılır
• When: Bir eylem gerçekleşir
• Then: Çıktı sağlanır

Gerçek hayatta ise bir giriş ekranını ele alacak olursak başarısız bir test şu şekilde yapılır;

• Given: Giriş formunda kullanıcı adı girilmiş, şifresi girilmemiş
• When: Giriş yap butonuna basıldığında
• Then: Başarısız bir doğrulama mesajı görüntülenmelidir

Başarılı bir testin yazımı ise şu şekilde olacaktır;

• Given: Giriş formunda kullanıcı adı ve şifre doğru şekilde girilmiştir
• When: Giriş yap butonuna basıldığında
• Then: Başarılı bir doğrulama mesajı görüntülenmelidir

BDD kullanmanın birçok avantajı da vardır. Bunlar;

• Teknik olmayan dil kullanımıyla daha geniş bir kitleye ulaşılmasına yardımcı olur
• Yazılımın davranışını tanımlarken daha üst bir soyutlama düzeyine geçersiniz ve böylece daha fazla iş fonksiyonu olan testler yazabilirsiniz
• Yazılım geliştiriciler, test uzmanları ve ürün sahipleri arasındaki iletişimi geliştirir
• Kabul kriterleri geliştirmeden önce oluşturulabilir

Uygulama için kabul testleri yazmak için kullanılan BDD çerçevesine dayalı bazı araçlar vardır. Bunlardan en bilineni Cucumber’dir. Cucumber ile iş analistleri, geliştiriciler ve test uzmanları için kolayca okunabilir ve anlaşılabilir bir formatta işlevsel doğrulamanın otomasyonu yapabilir. Cucumber, Selenium ile birlikte de kullanılabilir. Java diliyle birlikte Perl, PHP, Python, .Net gibi diğer birçok dili de desteklemektedir.

Kabul Testi Odaklı Geliştirme (Acceptance Test Driven Development)

Kabul Testi Odaklı Geliştirme testleri, kullanıcının bakış açısıyla tek bir kabul testi yazılır. Doğası gereği Davranış Odaklı Geliştirmeye benzer, ancak Kabul Testi Odaklı Geliştirme, esas olarak sistemin işlevsel davranışını tahmin etmeye odaklı, yazılımın gereksinimlerini karşılayan koda odaklanır. BDD gibi, testler düz metin olarak yazılır, ancak yazma kabulüne odaklanır. Yani ATDD, BDD’yi yürütülebilir bir test spesifikasyonuna dönüştürür ve bu spesifikasyon otomatik hale getirilebilir.

ATDD ile BDD arasındaki temel fark şu şekildedir: BDD, özelliğin davranışına daha çok odaklanırken, ATDD doğru gereksinimleri yakalamaya odaklanır.

ATDD’nin doğası gereği, yazılım geliştiriciler, kullanıcılar, ürün sahipleri ve testçiler arasında işbirliği yapılması gereklidir.

ATDD’nin avantajları ise;

• Gereksinimler, herhangi bir belirsizlik olmadan çok net bir şekilde analiz edilir
• Tüm ekip genelinde iletişimin iyi olmasını sağlar
• Kabul testleri, yazılımın ulaşması gerektiği noktaya doğru yönlendirir ve bir kılavuz görevi görür
• ATDD’nin otomasyonu geri bildirim süresini azaltabilir

Testin Önemi ve Stratejiler Arasındaki Farklar

Bir yazılımı test etmek önemlidir. Çünkü test metodolojileri yazılımın gerçekten olması gerektiği gibi çalışmasını sağlamaktadır.

Bu yöntemlerin nasıl çalıştığını anlamak, geliştiricilerin ve yazılım geliştirmeye dahil olan diğer bireylerin, amaçlarına hizmet etmek için hangi stratejinin en iyi sonucu verdiğini anlamalarına yardımcı olabilir.

TDD, BDD ve ATDD stratejilerinden en uygun olanını, mevcut ve gelecekteki projelerinizde kullanmanız yararlı olacaktır.

Son olarak TDD, BDD ve ATDD stratejileri arasındaki farkları hızlıca özetleyecek olursak;

• TDD daha tekniktir ve özelliğin uygulandığı aynı dilde yazılır. Örneğin Java ile uygulanıyorsa, JUnit testleri yazılır. BDD ve ATDD ise basit İngilizce dilinde metin olarak yazılır.
• TDD yaklaşımı, bir özelliğin uygulanmasına odaklanır. BDD, özelliğin davranışına odaklanır. ATDD ise, gereksinimleri yakalamaya odaklanır.
• TDD’yi uygulamak için teknik bilgiye sahip olmamız gerekir. BDD ve ATDD ise herhangi bir teknik bilgi gerektirmez. BDD ve ATDD’nin faydası, bu özelliği geliştirmeye hem teknik hem de teknik olmayan kişilerin katılabilmesidir.
• TDD geliştiğinden, iyi tasarım için alan sağlar ve gereksinimi karşılama yönüne odaklanır. BDD ve ATDD ise kullanıma uygun olan farklı bir yönüne odaklanır.

Sonuç olarak geleneksel geliştirme stratejilerinde kullanılan testi sonda yazma yaklaşımının aksine, tüm bu teknikler temelde öncelikle testi yazma yaklaşımından bahseder.