Testin ne olduğu değil, tüm ekipler için test edilmesi gereken bir soru önemlidir. Test, amaca ulaşmak için bir araçtır ve kod tabanınızın farklı parçalarını test etmeye nasıl öncelik verileceğini seçmek zor olabilir.
Önceliklendirmenin en iyi yolu kod tabanınıza ve ekibinizin hedeflerine bağlıdır. Bununla birlikte, geniş bir kod kapsamına sahip çok sayıda küçük test (ör. test piramidinin en altında) yazmak için zaman ve bant genişliği çok az olsa da bunların projenizin genel riskini azaltmayacağını unutmayın.
Uygulamanızın, web sitenizin veya kitaplığınızın temel kullanım alanlarını düşünerek ilk önce neyi test edeceğinizi seçebilirsiniz. Bunun için, sitenizin kritik bölümleri olan kullanıcı deneyiminin temelini oluşturan temel bileşenler üzerine bileşen testleri yazabilirsiniz. Örneğin, kullanıcıların zaman serisi verilerini yüklemesine ve yönetmesine izin veren bir sitenin geliştiricileri, bir kullanıcının bu görevleri gerçekleştirebileceği farklı yöntemleri hayal edip test etmelidir.
Önceliklendirmedeki bir başka yaklaşım da en fazla bilginin toplanmasını içerir. Kod tabanınızda "tehlikeli", eski veya kötü yazılmış bir yük taşıyan ve ekibinizdeki kimsenin üzerinde çalışmaktan hoşlanmayan bir parçası varsa daha fazla göz ardı etmeden veya düzeltmek için yeniden düzenlemeden önce davranışını daha tutarlı hale getirecek testler oluşturmak faydalı olabilir. Bunu, zaten hüküm giymiş ancak hâlâ veri merkezinizi barındıran bir binanın iskelesi gibi düşünün.
Boyutsallık
Test piramidi veya başka bir test şekli kavramını ortaya attık, ancak bunlar genellikle testin yalnızca tek bir boyutunu sunuyor: küçük kapsamlı, basit birim testlerinden karmaşık ve geniş kapsamlı testlere, birim testleri ve entegrasyon testleri ile uçtan uca testlere uzanan bir çizgi.
Ancak olası test türlerinden oluşan uzun listeden bazıları karmaşıklık düzeyini değil, test hedeflerini veya tekniklerini temsil eder. Örneğin, duman testleri kendileri de birim, uçtan uca veya başka testler olabilen farklı bir test kategorisidir. Ancak test kullanıcılarına projenin geçerli bir durumda olduğu konusunda genel güven vermeyi amaçlamaktadır. Görsel test, küçük bir bileşene veya bir bütün olarak sitenize de uygulanabilir.
Kod tabanınızın benzersiz gereksinimleri vardır. Örneğin, tek bir özellik üzerinde hizalamak, doğru çalıştığından emin olmak için farklı test türleri yazmak kod tabanınızda çok daha önemli olabilir. Test gerektiren yeni bir özellik, nadiren tek bir bileşen, işlev veya yaklaşımdan oluşur. Bu özelliğin projeniz üzerindeki etkisi geniş çapta ve farklı ölçeklerde dağıtılabilir.
Test öncelikleriniz iş ihtiyaçlarınıza da bağlı olabilir. İleri düzeyde teknik sistemler, benzersiz bir algoritmanın doğru performans gösterdiğini onaylamak için karmaşık birim testleri gerektirebilir. Öte yandan, yüksek düzeyde etkileşimli araçlar muhtemelen karmaşık dokunma girişlerinin doğru yanıtı sağladığını onaylamak için görsel testlere veya uçtan uca teste odaklanır.
Teste yaklaşımınız
Kod tabanınızın kullanım alanlarını, ölçekleri ne olursa olsun test etmeye odaklanmaya çalışın. Kullanıcının projenizin herhangi bir bölümünü nasıl kullanabileceğini hayal edin. Bu tek bir bileşeni, daha alt düzey bir işlevi ya da üst düzey bir uçtan uca kullanım alanını temsil ediyor olabilir. (Testinizin test edilen kodla düzgün bir şekilde etkileşimde bulunamadığını fark ederseniz, bu durum herhangi bir ölçekte soyutlamalarınızdaki eksiklikleri de ortaya çıkarabilir.)
Her test senaryosunun açıkça tanımlanmış bir hedefi olması önemlidir. Büyük "tümünü yakalama" testleri, test dışı kodunuzda olduğu gibi zorlayıcı olabilir.
Test odaklı geliştirmenin yanı sıra
Test odaklı geliştirme (TDD), en azından başlangıçta başarısız olması amaçlanan testlerin yazılmasını içerdiğinden (ölçek veya tür açısından dikey) test için benzersiz bir yaklaşımdır. Bu, hem manuel hem de otomatik test için geçerlidir: Ulaşmak istediğiniz hedefleri tanımlar, mevcut çözümünüzde veya kodunuzda nelerin eksik olduğunu bulursunuz ve başarısız testi çözüm için bir kılavuz olarak kullanırsınız.
Elbette, kurmadan önce bile varsayıma dayalı bir uygulama veya bileşende olası her senaryoyu test etmek faydalı değildir. TDD'nin kendine bir yeri vardır ve kod tabanınız daha karmaşık hale geldikçe bu özellik işinize yarayabilir.
TDD, hataları düzeltmek için de iyi bir uygulamadır. Bir hata için yeniden oluşturma durumunu kodlayabilirseniz bu, başlangıçta başarısız olacak otomatik bir teste dahil edilebilir. Hatayı düzelttiğinizde test başarılı olur ve manuel onay olmadan düzeltmenin başarılı olup olmadığını belirlemenize olanak tanır.
Opak mı yoksa şeffaf kutu mu?
Bu, sisteminizin herhangi bir bölümünü test etme yönteminizi ifade eder. Opaksa, örneğin bir sınıfın genel arayüzünü kullanırken dahili öğelerini incelemek yerine içini göremezsiniz.
Bunu yapmak için özel bir nedeniniz yoksa opak kutu testiyle başlamanız daha iyi olur. Böylece testleri bileşenlerinizin nasıl kullanıldığına göre tasarlayabilir ve iç öğelerinin çalışma şekliyle dikkatinizin dağılmamasını sağlayabilirsiniz. Yalnızca bir kod yolunun "herkese açık" arayüzünden yararlanırsanız (kullanıcılarınız için herkese açık olmasa da, kodunuzun diğer bölümleri için de herkese açık olabilir) testinizin tüm değişiklikleri algılayacağını bilerek bu kodu yeniden düzenleyebilir ve iyileştirebilirsiniz.
"Temiz kutu" kodunuzu daha opak hale getirmenin bir yolu, durumun diğer sistemlerle sıkı sıkıya bağlı olması yerine, kodun bağımlılıkları için soyutlamalar veya durumu gözlemlemek için geri çağırma gibi yapılandırılabilir öğeler kullanmaktır. Bu, kodunuzu daha bağımsız hale getirir ve "test" sürümleri sağlamanıza olanak tanır. Alternatif olarak, kodunuzun diğer sistemlerle etkileşim kurduğu yerin modelini de oluşturabilirsiniz.