İçeriğe geç

Django Rest ile Test Driven Development

Okuma süresi 5 dakika

Test Driven Development nedir?

Test Driven Development bir yazılım geliştirme tekniğidir. Türkçe’ye test güdümlü geliştirme olarak çevrilebilir. Süreç olarak bir kaç adım ve bunların kararlı bir şekilde tekrarlanması felsefesine dayanır.

  • Süreç ilk olarak uygulamanın bütün fonksiyonlarının teorik olarak küçük parçalara ayrılması ile başlar.
  • Daha sonra geliştirilmekte olan fonksiyonun testi yazılır.
  • Test çalıştırılır. Bu aşamada normal olarak test hata verecektir. Çünkü kullanılmak istenen fonksiyonun henüz uygulama tarafında bir karşılığı bulunmamaktadır.
  • Fonksiyon testin gereksinimleri karşılayacak şekilde geliştirilir.
  • Test tekrar çalıştırılır. Eğer test geçmiş ise minimum gereksinimler sağlanmıştır. Aksi durumda test edilen kaynak tekrar gözden geçirilerek gereksinimler doğrultusunda genişletilir.
  • Kod eğer imkan var ise tekrar düzenlenir. Optimizasyon, hazır yapıların kullanılması vs vs.
  • Yukarıdaki adımların her fonksiyon için tekrarlanması sonucunda uygulama geliştirilmiş olur.

Neden Test Driven Development?

Test Driven Development ile iş akışını ufak parçalar haline bölebilirsiniz.

Testler yazılır ve kod gereksinimleri karşılayacak şekilde oluşturulur, iyileştirme şansı varsa iyileştirilir. Bu yaklaşım size eklenen her fonksiyonun, özelliğin bir problemi, her zaman en efektik çözüm olmasa da kesinlikle çözdüğünü garanti eder.

Gün sonunda eklenen her özelliğin bir testi vardır. Bu yaklaşım uygulama büyüdükçe, veya yayına çıkmadan önceki olası bugların önüne geçmenize yardımcı olur.

Ekibe daha sonra katılacak bir yazılımcı testleri okuyarak uygulamanın yeteneklerine hızlıca adapte olabilir.

Yazılımları, uygulamaları yaşayan bir organizma olarak düşünür isek teorik olarak belirtilen bütün özellikler iş sonunda eklenmiş ve sınırları o versiyon için çizilmiş olacaktır. Bu da geliştirme maliyetini aşağıya çekecek o versiyon da kullanılmayacak özelliklere bağlı bugların da önüne geçecektir.

Ayrıca her ne olursa olsun neyin yanlış gittiğinden sadece bir test çalıştırma komutu uzaklığındayız.

Zaman kaybı mı?

TDD geliştirme sürecini daha uzun hale mi getirmektedir? Evet. Fakat burada kaybettiğiniz süre size debugging,refactoring maliyetlerinden kar olarak geri dönecek. Yanlış yönde son hız gitmektense bazen yavaşca hedefe gitmek daha iyidir.

Yukarıda da belirttiğim üzere yazılımlar veya uygulamalar yaşayan bir organizma ise sürekli büyüyecek, genişleyecek ve buna bağlı olarak kaynak kodu da genişleyecek.

TDD size sistematik olarak kod ile birlikte büyüyen bir test birikimi de sağlayacaktır. Bug-free!

Tabii ki çok hızlı geliştirme yapmanız gereken durumlarda veya tamami ile test edilmiş hazır yapıları özelliştirmeden kullanacağınız durumlarda bu yaklaşımı bir kenarda tutabilirsiniz. Bir Hackathon’da kimsenin derdi testler olmayacaktır 🙂


Django Rest Framework ve TDD

Django Rest Framework(DRF), Django üzerinde koşan projenize REST mimariye sahip bir API oluşturmak için yerleşik gelen bir çok özelliği ile size yardımcı olur.

  • Browsable API. ( API çerçevinizi göz atılabilir bir halde tarayıcınıza entegre eder. Harici bir uygulama kullanmadan endpointlerinizi HTML formatları kullanarak görebilir, HTML formları sayesinde POST,PUT,PATCH gibi işlemleri kolayca gerçekleştirebilirsiniz.)
  • Geniş kullanıcı doğrulama protokolleri. (Kimlik doğrulama, her uygulamanın en büyük parçalarından biridir. DRF kendi içinde bir çok doğrulama tipini destekler. 3.parti uygulamalar ile daha da genişletilebilir. Token authentication, ve JWT authentication ile alakalı bloglarda tutmuştum.)
  • Django felsefesine dayanan bir çok özellik. ( Serializers native Python data tiplerini XML veya JSON’a çevirmenize yardımcı olur. Generic viewlar ile hızlıca geliştirme yapmanızı sağlar.)
  • İyi dökümantasyon. (DRF’in gerçekten fazlası ile gelişmiş bir dökümantasyonu bulunmakta.)

Talk is cheap. Show me the code. -Linus Torvalds.


Django, DRF kullanarak TDD ile ufak bir uygulama gerçekleştirelim. Kullancılarımız kitaplıklarını dijital ortama aktarabilsinler, ve kitaplarının takibini yapabilsinler.

Basit bir model oluşturarak devam edelim. Bu aşamada yeni uygulamamız ve  migrationları veritabanına uygulayacağız. Bu yazıda default olarak Sqlite kullanılacaktır. Siz isterseniz farklı bir veritabanı ile çalışabilirsiniz.

Book uygulaması üzerinden gereklilikleri belirleyelim.

  • Kullanıcılar, kimliklerini token ile doğrulayacak. DRF token kullanılacak.
  • Kimliklerini doğrulamadan herhangi bir kaynağa erişemeyecekler.
  • Doğrulama sonrası kitap ekleyebilecek, kendine ait olanları listeleyebilecek, silebilecek ve düzenleyebilecek. (Hepimiz bir yerlerde CRUD yapıyoruz değil mi? 🙂 )

Let’s test!

İlk olarak test sınıflarını oluşturalım. Daha sonra test aşamalarını yazacağız.

  1. Doğrulanmamış kullanıcının reddi.
  2. Doğrulanmış kullanıcının kitaplarını listeleme.
  3. Var olan test datalarına API endpointi üzerinden kitap ekleme.
  4. Var olan kitapları API endpoint üzerinden düzenleme.
  5. Filtreleme ve serializasyonların doğru yapılıp yapılmadığının kontrolü.

Testleri çalıştırdığınızda beklenildiği üzere hata alacaksınız. Çünkü henüz bir serializera, api isteklerini karşılayacak bir view ve main url dosyasından book uygulamasını bir yönlendirme tanımlamadık. Testi geçebilmek için sırası ile bu adımları yapalım.

Book uygulaması içinde api adlı bir klasör oluşturun. Daha sonra serializers.py.

book/api/views.py

book/api/urls.py

library/urls.py

Testleri tekrar çalıştırın. Bu sefer geçecek. Testlerin gereksinimini şu anlık karşılamakta.

Yukarıda yapılanları hızlıca özetleyecek olursam, Book modelinin nesnelerini JSON veya XML formatına dönüştürmek için bir serializer tanımladık.

Daha sonra gelecek istekleri karşılamak için bir API viewi yazdık. DRF’te bu işi yapmanın bir çok yolu bulunmakta. Burada viewsetler kullanıldı. Generic viewset ve mixin olarak listmodelmixinden türetildi.

Bu view için kullanıcı doğrulaması olarak TokenAuthentication kullanılacağını belirttik. Ve sadece doğrulanmış kullanıcıların bu viewa erişimi olacağını belirttik.

Viewsetler diğer url endpointleri için router adlı bir kavram ile birlikte gelmekte. Bizim için kaydedilen viewsetin url endpointlerini otomatik olarak yönetmekte.

Main url dosyasından book uygulamasına yönlendirme yapıldı.

Devam edelim.


Testlerin gereksinimleri şu anda karşılanmakta.

Bu yaklaşım belki yavaş gibi gözükebilir fakat ileride uygulama beklenmeyen davranışlar gösterdiğinde debug edip problemi çözmekten daha pragmatik ve basit.

KISS 🙂 (Keep It Simple Stupid)


Son adım olarakta test edilen kaynağın iyileştirilebileceğinden bahsetmiştik.

ModelViewSet kullanarak hazır bir yapı kullanarak mixin kalabalığından kurtulmuş olduk.


Son sözler.

Eğer TDD yaklaşımı ile bir uygulama geliştiriyor iseniz herhangi bir Continuous Integration tooluna bağlamak fazlasıyla hayat kurtarıcı olabilir.

Uygulama üzerindeki değişikliklerin deployment anında kullanılacak olan teknolojilerle birlikte çalışabildiğini de garanti altına almış olur, hızlı dağıtım yaparsınız.

Tabii ki Continuous Integration yaklaşımı sadece bununla sınırlı değil.

Fakat konuyu fazla dağıtacağını düşündüğümden burada kesiyorum.

Artık TDD ve DRF ile bu yaklaşımın nasıl uygulanbileceği hakkında fikir sahibisiniz.

Görüşmek üzere!

 

 

 

 

 

 

 

 

Tarih:Blog

İlk Yorumu Siz Yapın

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Göster
Gizle