Gerçek Dünyada, başkasının kodu için birim testleri yazmak kesinlikle normaldir. Elbette, orijinal geliştirici bunu zaten yapmış olmalı, ancak genellikle bunun henüz yapılmadığı eski kodu alırsınız. Arada, söz konusu eski kod çok, çok uzak bir galaksiden yıl önce geldi, yoksa iş arkadaşlarınızla biri geçen hafta içinde kontrol ya da bugün yazdım, ister eski kodu olup olmadığı önemli değildir testler olmadan kod
Kendinize sorun: Neden birim testleri yazıyoruz? Yeşil Olmak açık bir şekilde sadece bir amaç için bir araçtır, nihai amaç test edilen kodla ilgili iddiaları kanıtlamak veya çürütmektir.
Kayan nokta sayısının karekökünü hesaplayan bir yönteminiz olduğunu varsayalım. Java'da arayüz bunu şöyle tanımlar:
public double squareRoot(double number);
Uygulamayı yazıp yazmadığınızdan veya bir başkasının yazıp yazmadığının bir önemi yoktur, squareRoot'un birkaç özelliğini öne çıkarmak istersiniz:
- sqrt (4.0) gibi basit kökleri döndürebileceğini
- makul bir hassasiyetle sqrt (2.0) gibi gerçek bir kök bulabileceğini
- sqrt (0.0) 'ın 0.0 olduğunu bulur.
- negatif bir sayı verildiğinde bir IllegalArgumentException özel durumu atar, yani sqrt (-1.0)
Bunları bireysel testler olarak yazmaya başlıyorsunuz:
@Test
public void canFindSimpleRoot() {
assertEquals(2, squareRoot(4), epsilon);
}
Hata! Bu test zaten başarısız:
java.lang.AssertionError: Use assertEquals(expected, actual, delta) to compare floating-point numbers
Kayan nokta aritmetiği unuttun. Tamam, siz tanıtın double epsilon=0.01ve gidin:
@Test
public void canFindSimpleRootToEpsilonPrecision() {
assertEquals(2, squareRoot(4), epsilon);
}
ve diğer testleri ekleyin: sonunda
@Test
@ExpectedException(IllegalArgumentException.class)
public void throwsExceptionOnNegativeInput() {
assertEquals(-1, squareRoot(-1), epsilon);
}
ve ayy, yine:
java.lang.AssertionError: expected:<-1.0> but was:<NaN>
Test etmelisiniz:
@Test
public void returnsNaNOnNegativeInput() {
assertEquals(Double.NaN, squareRoot(-1), epsilon);
}
Burada ne yaptık? Yöntemin nasıl davranması gerektiği konusunda birkaç varsayımla başladık ve hepsinin doğru olmadığını gördük. Daha sonra yöntemin düzeltilmiş varsayımlarımıza göre davrandığını kanıtlamak için test paketini Yeşil yaptık. Artık bu kodun istemcileri bu davranışa güvenebilir. Birisi squareRoot'un gerçek uygulamasını başka bir şeyle değiştirecek olsaydı, örneğin NaN döndürmek yerine gerçekten bir istisna atan bir şey varsa, testlerimiz bunu hemen yakalayacaktı.
Bu örnek önemsizdir, ancak genellikle gerçekte ne yaptığının belirsiz olduğu büyük kod parçalarını miras alırsınız. Bu durumda, kodun etrafına bir test bandı yerleştirmek normaldir. Kodun nasıl davranması gerektiği hakkında birkaç temel varsayımla başlayın, onlar için birim testleri yazın, test edin. Yeşil ise, iyi, daha fazla test yazın. Kırmızı ise, şimdi bir spesifikasyona karşı tutabileceğiniz konusunda başarısız bir iddianız var. Belki eski kodda bir hata var. Belki de spesifikasyon bu girdi hakkında net değil. Belki bir özelliğiniz yok. Bu durumda, testi beklenmedik davranışı belgeleyecek şekilde yeniden yazın:
@Test
public void throwsNoExceptionOnNegativeInput() {
assertNotNull(squareRoot(-1)); // Shouldn't this fail?
}
Zamanla, kodun gerçekte nasıl davrandığını belgeleyen ve bir tür kodlu bir spesifikasyon haline gelen bir test koşumuyla sonuçlanırsınız. Eski kodu değiştirmek veya başka bir kodla değiştirmek isterseniz, yeni kodun aynı şekilde davrandığını veya yeni kodun beklenen ve kontrol edilen şekilde farklı davrandığını doğrulamak için test cihazına sahipsiniz (örneğin, aslında düzeltmesini beklediğiniz hatayı düzeltir). Bu koşum takımının ilk günde tamamlanması gerekmez, aslında, eksik bir koşum takımına sahip olmak neredeyse hiç koşum takımına sahip olmaktan daha iyidir. Bir koşum takımına sahip olmak, müşteri kodunuzu daha kolay yazabileceğiniz anlamına gelir, bir şeyi değiştirdiğinizde bir şeylerin nerede kırılacağını ve nihayetinde bozulduklarında nerede kırıldıklarını bilirsiniz.
Sadece bir formdaki zorunlu alanları doldurmanız gerektiği gibi, birim testleri yazmak zorunda olduğunuz zihniyetten çıkmaya çalışmalısınız. Ve sadece kırmızı çizgiyi yeşil yapmak için birim testleri yazmamalısınız. Birim testleri düşman değil, birim testleri arkadaşlarınızdır.