Unit Tests - Birim Testleri
Birim Testleri (Unit Tests)
http://www.extremeprogramming.org/rules/unittests.html
Birim testleri Extreme Programming’in (XP) köşetaşlarından biridir. Ancak XP tarzı birim testleri biraz farklıdır. Önce otomatik birim testleri oluşturmak için bir birim testi frameworkü oluşturur veya indirirsiniz. İkinci olarak sistemdeki tüm sınıfları test edersiniz. Önemsiz getter-setter metotları genelde yoksayılır. Ayrıca, testlerinizi kodu oluşturmadan önce oluşturursunuz.
Birim testleri kod deposuna test ettikleri kodla birlikte gönderilirler. Testleri olmayan kod yayınlanmaz. Eğer bir birim testinin eksik olduğu görülürse, eksik test fark edildiği anda oluşturulmalıdır.
Birim testlerine bu kadar zaman adamaya karşı en büyük direniş yaklaşan teslim tarihidir. Ancak bir projenin yaşam döngüsünde bir birim testi, hataları bularak ve hatalara karşı koruma sağlayarak testi oluşturmanın maliyetinden yüz kat fazla kazanmanızı sağlayabilir.
Bir diğer yanlış anlama da birim testlerinin projenin son üç ayında yazılabileceği düşüncesidir. Ne yazık ki, birim testleri olmadan geliştirme sürünür ve o son üç ayı da zaten tüketir ve hatta biraz daha zamanı da. Zaman uygun olsa bile iyi birim testi süitlerinin gelişmek için zamana ihtiyaçları vardır. Tüm problemleri keşfetmek zaman alır. Eğer ihtiyaç anında kullanacağınız tam bir birim testi süitiniz yoksa, bugün oluşturmaya başlamalısınız.
Birim testleri ortak sahiplik sağlar. Birim testleri oluşturduğunuzda fonksiyonalitenizi kazara zarar görmekten korursunuz. Yayınlanmadan önce tüm işlevlerin birim testlerinin geçmesinin gerekmesi, tüm fonksiyonalitenin her zaman çalışır durumda olmasını sağlar. Tüm sınıflar birim testleri tarafından gözetildiğinde kişisel kod sahipliğine de gerek kalmaz.
Birim testleri yeniden düzenlemeyi (refactoring) de sağlar. Her küçük değişiklikten sonra birim testleri yapıdaki değişikliğin fonksiyonalitede bir değişikliğe neden olmadığını doğrular.
Validasyon ve regresyon testleri için evrensel bir birim testi süiti kurmak sık entegrasyonu sağlar. Herhangi bir güncel değişikliği hızlıca entegre etmek ve test süitinin son versiyonunu çalıştırmak mümkündür. Eğer bir test başarısız olursa sizin son versiyonunuz takımınızın son versiyonu ile uyumsuzdur. Birkaç saat içinde küçük sorunları çözmek, teslim tarihinden önce devasa sorunları çözmekten daha az zaman alır. Otomatize edilmiş birim testleri sayesindde bir değişiklik setini yayınlanmış güncel versiyonla birleştirmek ve kısa sürede yayınlamak mümkündür.
Yeni işlevsellik eklemek, sıklıkla işlevselliği yansıtmak için birim testlerinin de değiştirilmesine ihtiyaç duyar. Hem kodda, hem de testte bir hata (bug) oluşturmak olası olsa da, bu durum pratikte nadiren yaşanır. Genelde olan şey testin yanlış, kodun ise doğru olmasıdır. Sorun incelendiğinde ve düzeltildiğinde bu durum ortaya çıkar. Kodlardan bağımsız testler oluşturmak, ümit edilir ki bunu koddan önce yapmak, kontrol mekanizmalarını kurar ve ilk seferinde doğru yapma şansını büyük ölçüde artırır.
Birim testleri regresyon ve validasyon testlerinden oluşan bir güvenlik ağı sağlar, böylece kodu yeniden düzenlersiniz (refactoring) ve etkin bir biçimde entegre edersiniz. Sirklerde dedikleri gibi; asla bir ağ olmadan çalışma! Birim testlerini koddan önce oluşturmanın, gereksinimleri netleştirmek, geliştiricinin odaklanmasını arttırmak ve creeping elegance’ı önlemek gibi yararları da vardır.
Birim testi frameworkleriyle ilgili en genel yanlış anlama, bunların sadece test etme araçları olmasına inanılmasıdır. Test frameworkleri editörünüz ve derleyicinizin olduğu gibi geliştirme araçlarıdır. Bu güçlü geliştirme aracını projenin son ayına kadar bekletmeyin, proje boyunca kullanın ve ondan yararlanın. Birim testi süitiniz gereksinimleri formalize etmeye, mimariyi daha açık hale getirmeye, kod yazmaya, hata ayıklamaya, kodu entegre etmeye, yayınlamaya, optimize etmeye ve tabi ki test etmeye yarar.
Ayrıca Bakınız
Last updated