android-web-tester

Android uygulama geliştirmeye test güdümlü yaklaşım

Web ve Mobil uygulamalar geliştirerek geçirdiğim yıllardan sonra çok basit bir şekilde söylemem gerekir ki, bir heyecanla hemen bilgisayarlarımızı açıp yönetmeye başladığımız projelerin çoğu bir süre sonra biz programcıları yönetmeye başlıyor.

Uygulama büyümeye başladıkça kod satırları artıyor, birbirini kullanan methodlar çoğalıyor, aynı kodlar tekrar tekrar yazılıyor ve uygulamaya her ekleyeceğimiz kod parçasından önce artık “acaba bu ekleyeceğim kod nereleri bozacak” diye korkmaya başlıyoruz. “A“ alanına eklediğiniz bir kod parçası “Z” alanında bozulmalara sebebiyet veriyor. Hatayı bulabilmek için saatlerimizi harcıyoruz, Stackoverflow sayfalarını arşınlıyoruz. Ufacık bir hatayı tamir edelim derken başka hatalar almaya başlıyoruz. Sonra uygulama üstündeki tüm kontrolü kaybetmeye giderek daha çok yaklaşıyoruz. Sonunda birden hatalar düzeliyor ancak bunu nasıl yaptığınızı bilmiyorsunuz. Hala da başka bir “X” alanını bozmadığımızdan emin değilsiniz. Artık her run tuşuna bastığınızda sonuç aşağıdaki gibi oluyor.

Why Programmers Scare Refactor

Durun! Hemen ümidinizi kaybetmeyin. Henüz bütün çarelerimizi tüketmedik. Tabi şu andan itibaren TDD (Test Driven Development) programlama hayatınızın bir parçası olarak kabul etmezseniz. Öncelikle neden programcıların kodunu değiştirmekten korkacak hale geldiği üzerinde biraz duralım.

  • Güven eksikliği! Programcılar kendi yapacakları değişiklere güvenmiyorlar. Çünkü değişiklik yaptıkları kodun bağımlı olduğu diğer kodları bozup bozmadığından emin değiller.
  • Eğer gerçekten uygulama doğru çalışmazsa, kaç adet satırı tekrar bakmaları gerektiğini düşünüyorlar.
  • Son olarak da ekledikleri kod çalışsa bile, tam olarak sebebini hala bilmiyorlar.

Biraz TDD konuşalım

Eğer TDD mantığıyla ilk kez karşılaşıyorsanız ilk zamanlar işin mantığını kavraması zor olabilir. Ancak korkmayın ve denemeye devam edin.

İlk olarak sizlere test piradimizden bahsetmek istiyorum. Aslında burada gösterilen piramit daha fazla katmana da sahip olabiliyor ancak şimdilik bizim için bu yeterli.

Test Driven Development Pyramid

Resimde de gördüğünüz üzere katmanımızın en altında Unit Test bulunuyor “ki bu da bizim blogumuzun ilk parçasının ana konusu olacak”. Unit Testi teknik olarak incelemeye başlarsak; kodun en küçük parçasının test edilmesi olarak tanımlayabiliriz. Kodun en küçük parçası bizim için sınıflarımız içerisindeki metotlarımızdır. Her bir sınıf içerisinde bulunan tüm metotlarımızı karşımıza çıkabileceğinizi düşündüğümüz tüm durumları göz önüne alarak testlerimizi yazmayı başarabilirsek bunun bize kazandıracakları şunlardır;

  • Debugging maliyetlerinin azalması – Birbirine bağımlı sınıflara eklediğiniz yeni becerilerden birisi eğer diğer sınıflarda bulunan başka bir metoddan beklenen çalışma biçimini bozması durumunda bu hatayı yakalayabilmek için sayfa sayfa gezip break pointler koymak yerine sadece unit test Suit sınıfımız çalıştırarak hatalı metodu saniyeler içinde yakalayabiliriz.
  • Yazılımın kendini dokumente etmesi – Unit test ile yazılan kodunuz genellikle diğer programcılar tarafından kolayca anlaşılabilir hale gelir.
  • Kodunuz daha temiz hale gelir – Yazılan progam için Unit test yazılması için kodunuzun belli bir yazılım desenine  bağlı olması gerekiyor. Bu da sınıflarınızı daha anlaşılır, birbirlerinize olan bağımlılığı az halde olmasına yarar (burada SOLID prensiplerine değinmek gerekir ancak bu başka bir yazımızın konusu olacak).

Android uygulamaları geliştirirken eğer kodunuzun test edilebilir olmasını istiyorsanız mutlaka MVP yazılım desenini öğrenmenizi ve kodunuzu buna göre hazırlamanızı tavsiye ederim. MVP yazılım desenine uygun şekilde kod yazmaya başladığınız zaman kodun kalitesine ve kendinizdeki gelişmeye sizde şaşıracağınıza eminim.

Tamam ama nerden başlamalıyım ?

Her bir yazılım dili için farklı test araçları var benim uzmanlık alanım Android uygulama geliştirme olduğu için direk olarak bu konudan bahsedeceğim. Aslında aşağıda bahsedeceğim her bir tool için ayrıca bir blog yazılması gerekir ancak ben kısaca bahsederek geçeceğim.

Junit – Junit tekrarlanabilir testler yazmak için tasarlanmış hafif ve hızlı bir test aracıdır. Java için üretilmiştir ve ek araçlarla uygun şekilde çalışır. xUnit mimarisi üzerine kurulmuştur.

Robolectric – Robolectric en kullanışlı test araçlarımızdan birisidir. Herhangi bir cihaza(mobil cihaz / emulator )  ihtiyaç duymadan Android componentlerine erişebilir. Aslında bu çok önemli bir özellik bizim için ancak bunun ne kadar kıymetli olduğunu çok fazla test yazıp mantığını oturtunca daha iyi anlayacaksınız.

Mockito – Mock objelere yaratmak için kullanılan en yaygın test aracıdır. Tek başına bir anlam ifade etmez ve Junit/Robolectric gibi diğer test araçlarıyla beraber kullanılır. Tabi burda Mock nedir ve altında ne yatar bunu da anlatmak gerekir ama bu da farklı bir bloğumuzun konusu.

AssertJ – Yine Java için yazılmış, test kalitemizi arttırıcak ve daha temiz, detaylı ve anlaşılır testleri yazmamızı sağlayacak bir yardımcı araçtır.

Hamcrest – AssertJ ile aynı tanıma sahip. İkisinden birisi tercih edilebilir. Ben genelde assertJ tercih ettiğim için öne aldım. Ancak Hamcrest de çok farklı bir syntax’a sahip değil.

Bonus

Pragmatists – Benim sürekli olarka kullandığım ve çok faydasını gördüğüm bir yardımcı araç daha. Bu araç sayesinde de teslerimizi farklı parametrelerle test edip, kodun farkılı varyasyonlarda nasıl davrandığınızı test edebiliriz.

 

Etiketler:
Bir Sonraki Yazı

İlk adım: Kurumsal kimlik

Bir Önceki Yazı

Sunum tasarım süreci hakkında 7 önemli nokta

Bir Cevap Yazın

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