Test Odaklı Geliştirme şu anda sektördeki pek çok moda sözcükten yalnızca biri. Bu yüzden insanların bu konuda kafalarının karışık olması son derece normal.
- Test Odaklı Geliştirme (TDD → Test Driven Development)
- Davranış Odaklı Geliştirme (BDD → Behavior Driven Development)
- Kabul Testi Odaklı Geliştirme (ATTD → Acceptance Test Driven Development)
- DevOps
- DevSecOps
- Sürekli Test
- Model Tabanlı Test
Liste böyle uzayıp gidiyor.
Ancak hata yapmayın. Tüm bu uygulamalar ve metodolojiler aslında tek bir soruya cevap arar. “Daha iyi” bir yazılımı nasıl geliştirebiliriz?
Bu yazımda, Test Odaklı Geliştirme, Davranış Odaklı Geliştirme ve Kabul Testi Odaklı Geliştirme ile ilgili kafanızdaki tüm soru işaretlerini gidermeye çalışacağım. Nedir? Nasıl çalışır? Ayrıca geliştirme/test süreci üzerindeki etkileri nelerdir?
Test Odaklı Geliştirme (TOG): “Kod Doğru Mu?”
Test Odaklı Geliştirme, iç-dış perspektifine odaklanır; yani testleri geliştiricinin bakış açısından oluştururuz. “Bu kod doğru mu?” sorusu Test Odaklı Geliştirme’nin ardındaki ana sorudur.
Metodoloji özellikle “birim testlerine” odaklanır. Geliştirici bir gereksinimi alır ve onu belirli bir test case’ine dönüştürür. Daha sonra da geliştirici yalnızca bu belirli testleri geçebilecek kodu yazar. Bu pratikle gereksinimleri karşılamayan lüzumsuz güncellemeleri önlemek amaçlanmaktadır. Test Odaklı Geliştirme, geliştiricilerin kodu yazdıktan sonra Birim Testleri yazdıkları geleneksel programlamadan farklı olarak, geliştiricileri kodu yazmadan önce ürün gereksinimlerine odaklanmaları için zorlar.
TOG, Kent Beck’in, “Test Driven Development: By Example” kitabında bahsettiği gibi 6 adımdan oluşan basit bir işlemdir. Şimdi gelin, Spotify kataloğundan belirli bir albümü yayınlama örneğini hep birlikte inceleyelim.
Adım 1: Testi ekle
İlk adım bir gereksinimi almak ve bu gereksinimi özellik tanımlamalarının (feature specifications) geliştirici tarafından tam anlaşılabileceği netlikte bir teste dönüştürmektir.
Varsayalım ki Spotify için çalışıyoruz ve bir abonenin belirli bir albümü arayabileceği ve yayınlayabileceği bir özellik oluşturmak istiyoruz. Bu durumda test, kullanıcı ücretli bir abone mi, albüm Spotify kataloğunda var mı, albümün lisansı alınmış mı? Eğer tüm koşullar yerine getirildiğinde albümü yayınlanabilir.
Adım 2: Bütün testleri koşun ve yeni testin başarısız olup olmadığını gözlemleyin
Sonraki adım başarısız olduğundan emin olmak için testi koşmaktır. Eğer test başarılı olursa bu demektir ki istenen davranış çoktan mevcut, dolayısıyla yeni koda gerek yok ya da yeni testte hata var ve değiştirilmesi gerekiyor.
Şimdi başarısız olduğundan emin olmak için testi koşmalıyız. Kullanıcı belirli bir albümü arayamamalı ve yayınlayamamalı.
Adım 3: Kodu yazın
Bu adımda geliştirici testi geçebilecek kodu yazar. Bu aşamada kodun kalitesi önemli değildir. Geliştiricinin tek hedefi testi geçecek kodu yazmaktır.
Örneğimizdeki geliştirici, Spotify abonelerinin belirli bir albümü aramalarını ve yayınlamalarını sağlamak için gerekli kodu yazmalıdır.
Adım 4: Testleri koşun
Tüm testleri koşuyoruz. Eğer bütün testler başarılı olursa kodun bütün gereksinimleri karşıladığından ve var olan özellikleri etkilemediği için tatmin oluruz. Eğer tüm testler başarılı olmazsa geliştiricinin kodu düzenlemeye devam etmesi gerekir.
Örneğimizdeki testçi, belirli bir albüm arayabilmeli, diyelim ki Childish Gambino’dan “Because The Internet” parçası olsun ve parçayı yayınlayabilmeli.
Adım 5: Kodu iyileştirin
Tüm testler başarılı geçtikten sonra hijyen standartları doğrultusunda yeni kodun temizlenmesi gerekiyor.
Adım 6: Tekrarla
“Tekrarla” illaki bir sonraki adım olmak zorunda değildir. Ancak yeni gereksinimler varsa veya yazılımın işlevselliği geliştirilmek isteniyorsa, geliştiricinin süreci tekrar etmesi gerektiğine dair bir hatırlatma işlevi görür.
Tipik olarak, Test Odaklı Geliştirme’yi uygulayan ekipler başlangıçta geliştirme maliyetlerinde artış, hata oranlarında ciddi miktarda düşüşler görürler. Bunlara ek olarak Test Odaklı Geliştirme, modüler, esnek ve genişletilebilir kodun kalitesinde iyileşme sağlar.
Davranış Odaklı Geliştirme (DOG) – ”Bu, test etmemiz gereken şey mi?”
Davranış Odaklı Geliştirme, “dıştan içe” bakış açısına odaklanır; yani iş çıktılarıyla ilgili davranışları test eder. Süreç, Test Odaklı Geliştirme’ye çok benzer. Ancak, bir iş çıktısının amaç ile bağlantısından emin olmak için her kullanıcı hikâyesine “Five Why’s” ilkesini uyguluyorsunuz. DOG, bir kullanıcı hikâyesinin “why”larının yanıtlarından emin olmak için geliştiricilerin, testçilerin ve kullanıcıların rehberliğine ihtiyaç duyar. Tüm bunlar DOG’nin ardındaki ana soruyu ortaya çıkarır: “Bu test etmemiz gereken şey mi?”
DOG, büyük oranda TOG’nin bir uzantısıdır. Geliştirici bir test tanımlar ve sonra da testin başarısız olacağına dair kodu test eder. Daha sonra geliştirici bu test senaryosunu geçmek için gereken kodu yazar ve ardından uyumluluğundan emin olmak için kodu test eder. DOG’nin TOG’den farklı olduğu yer testin nasıl belirtildiğidir. DOG testleri istenen davranışı belirten bir formdadır. DOG testlerinin net ve anlaşılır dili geliştirme projesindeki tüm paydaşlar tarafından projenin anlaşılmasını kolaylaştırır. Aşağıda Spotify’da belirli bir albümü yayınlamaya çalışan bir kullanıcı için DOG test örneği yer alıyor.
| Story | Spotify’da belirli bir albümü yayınlamak | Kullanıcı hikâyesinin tanımı |
| As a | Bir Spotify abonesi olarak | “kim?” → kullanıcı hikâyesinin birincil paydaşı |
| In order to | Favori albümümü çalmak için | “ne?” → kullanıcı hikâyesinin birincil paydaş üzerindeki etkisi |
| I want to | Spotify kataloğunda favori albümümü aramak ve yayınlamak istiyorum | “neden?” → birincil paydaşa değeri |
Senaryo 1:
| Given | Lisanslı Childish Gambino parçası | koşul |
| And | Kullanıcı Spotify servisinin bir abonesi | koşul |
| When | Abone Spotify kataloğundan Childish Gambino’nun “Because the Internet” albümünü seçtiğinde | olay tetiklendiğinde |
| Then | Spotify servisi kullanıcı için Childish Gambino’ nun “Because the Internet” albümünü yayınlar | beklenen sonuç |
DOG, uygulayıcılara birçok önemli avantaj sunar. DOG metodolojisi geliştiricilerin, testçilerin ve kullanıcıların iş birliği yapmasını kolaylaştırmak için güvenilir bir yapı ve format sağlar. DOG testlerini yazarken kullanılan basit dil ve spesifikasyon her seviyeden insanın benimsemesini kolaylaştırır. Son olarak metodoloji kullanıcı hikayelerinin iş çıktılarına odaklanmasını sağlar.
Kabul Testi Odaklı Geliştirme (KTOG) – “Kod yapması gerekeni yapıyor mu?”
Kabul Testi Odaklı Geliştirme (KTOG), kod yazmadan önce Kabul Testlerinin varlığından emin olmak için kullanıcı, geliştirici ve testçi arasında iş birliğini teşvik etmeyi amaçlar. Kabul Testi kullanıcının bakış açısından yazılır ve yazılımın nasıl çalışması gerektiğine dair bir gereksinim olarak işlev görür. “Kod yapılması isteneni yerine getiriyor mu?” sorusu KTOG’nin ardındaki ana sorudur.
| Given | Verilen Spotify kataloğunda lisanslı albüm | kurulum, belirtilen durum |
| And | Kullanıcı ücretli bir abone | kurulum devam ediyor |
| When | Abone Spotify kataloğundan albüm seçtiğinde | tetiklenme |
| Then | İstenen albüm çalmaya başlar | doğrulama, çıktı üretildi veya durum değişti |
KTOG’nin en büyük faydası uygulamaların tasarım açısından Birim Test’lerinde kolaylaşmasıdır.
| TOG | DOG | KTOG | |
| Paydaşlar | Geliştirici | Müşteri, Geliştirici, Testçi | Müşteri, Geliştirici, Testçi |
| Odak | Birim Test | Gereksinimler | Kabul Testleri |
| Zorluk seviyesi | Kolay | Zor | Zor |
| Araçlar | Gherkin, Cucumber, Easy, JDave, Concordion, JBehave, FitNesse, BeanSpec, Specflow | Gherkin, Cucumber, Easy, JDave, Concordion, JBehave, FitNesse, BeanSpec, Specflow | TestNG, FitNesse, Cucumber, JBehave, Concordion, EasyB |
| Değer | Yeni özellikler, gereksinimlere odaklanmıştır. | Yeni özellikler, iş çıktılarıyla uyumludur. | Birim Testlerinin uygulanmasını kolaylaştırır. |
TOG, iyi yazılmış kod birimlerini destekleyen geliştirici odaklı bir metodolojiyi benimsemiştir. Öte yandan KTOG müşteriler, geliştirme ve kalite güvencesi arasında iş birliğini teşvik etmek için tasarlanmış bir metodolojidir. DOG, TOG’nin genişletilmiş halidir.
Kaynak: https://www.ca.com/en/blog-agile-requirements-designer/guide-to-test-driven-development-tdd-vs-bdd-vs-atdd.html