Tesadüfi Davranış Değil, Gerekli Davranış Testi

Test etmedeki yaygın bir tuzak, bir uygulamanın tam olarak ne yaptığını tam olarak test etmek istediğiniz şey olduğunu varsaymaktır. İlk bakışta bu bir tuzaktan çok bir erdem gibi geliyor. Bununla birlikte, başka bir şekilde ifade edilirse, sorun daha açık hale gelir: Testlerdeki yaygın bir tuzak, testleri bir uygulamanın özelliklerine bağlamaktır, burada bu özellikler tesadüfidir ve istenen işlevsellik üzerinde hiçbir etkisi yoktur.

Testler, uygulama tesadüflerine bağlı olduğunda, gerekli davranışla gerçekten uyumlu olan uygulamada yapılan değişiklikler, testlerin başarısız olmasına ve yanlış pozitiflere yol açmasına neden olabilir. Programcılar genellikle ya testi yeniden yazarak ya da kodu yeniden yazarak yanıt verirler. Yanlış bir pozitifin aslında gerçek bir pozitif olduğunu varsaymak genellikle korku, belirsizlik veya şüphenin bir sonucudur. Tesadüfi davranışın statüsünü istenen davranışa yükseltme etkisine sahiptir. Bir testi yeniden yazarken, programcılar ya testi gerekli davranışa yeniden odaklarlar (iyi) ya da basitçe yeni uygulamaya (iyi değil) bağlarlar. Testlerin yeterince kesin olması gerekir, ancak aynı zamanda doğru olmaları gerekir.

Örneğin, C'nin strcmp veya Java'nın String.compareTo gibi üç yönlü bir karşılaştırmada, sonuçtaki gereksinimler, sol taraf sağdan küçükse negatif, sol taraf sağdan büyükse pozitif ve eşit olarak kabul edilirse sıfır olmasıdır. Bu karşılaştırma stili, C'nin qsort işlevi için karşılaştırıcı ve Java'nın Karşılaştırılabilir arabirimindeki compareTo dahil olmak üzere birçok API'de kullanılır. Belirli -1 ve +1 değerleri, uygulamalarda sırasıyla küçüktür ve büyüktür belirtmek için yaygın olarak kullanılsa da, programcılar sıklıkla yanlışlıkla bu değerlerin gerçek gereksinimi temsil ettiğini varsaymakta ve sonuç olarak bunu sağlayan testler yazmaktadır.

Benzer bir sorun, boşluk, kesin ifadeler ve metinsel biçimlendirme ve sunumun tesadüfi olan diğer yönlerini öne süren testlerde ortaya çıkar. Örneğin, yapılandırılabilir biçimlendirme sunan bir XML oluşturucu yazmıyorsanız, sonuç için boşluk önemli olmamalıdır. Benzer şekilde, düğmelerin ve etiketlerin UI kontrollerine donanım bağlantısıyla yerleştirilmesi, gelecekte bu olası durumları değiştirme ve iyileştirme seçeneğini azaltır. Uygulamadaki küçük değişiklikler ve biçimlendirmedeki önemsiz değişiklikler aniden yapı kesiciler haline gelir.

Aşırı belirtilmiş testler, genellikle birim testine yönelik beyaz kutu yaklaşımlarıyla ilgili bir sorundur. Beyaz kutu testleri, gereken test senaryolarını belirlemek için kodun yapısını kullanır. Beyaz kutu testinin tipik başarısızlık modu, testlerin sonunda kodun, kodun yaptığını yaptığını iddia etmesidir. Basitçe, koddan zaten bariz olanı yeniden yazmak hiçbir değer katmaz ve yanlış bir ilerleme ve güvenlik duygusuna yol açar.

Etkili olması için, testlerin papağan uygulamalarından ziyade sözleşme yükümlülüklerini belirtmesi gerekir. Arayüz sözleşmelerini yürütülebilir biçimde çizerek, test edilen birimlerin kara kutu görünümünü almaları gerekir. Bu nedenle, test edilen davranışı gerekli davranışla hizalayın.

Kevlin Henney Tarafından