Bütün bağımlılıkları yerinde test etmek hala önemlidir, ancak Jeffrey Faust'un söylediği gibi entegrasyon testi alanında daha önemlidir.
Birim testinin en önemli yönlerinden biri, testlerinizi güvenilir hale getirmektir. Başarılı bir testin gerçekten işlerin iyi olduğu ve başarısız testin üretim kodunda bir sorun olduğu anlamına gelmediğine güvenmiyorsanız, testleriniz neredeyse onlar kadar faydalı değildir.
Testlerinizi güvenilir hale getirmek için birkaç şey yapmanız gerekir, ancak bu cevap için sadece bir taneye odaklanacağım. Çalıştırmanın kolay olduğundan emin olmanız gerekir, böylece tüm geliştiriciler kodu girmeden önce kolayca çalıştırabilirler. "Çalıştırması kolay", testlerinizin hızlı bir şekilde çalıştığı ve bunları yapmak için gereken kapsamlı bir yapılandırma veya kurulum olmadığı anlamına gelir . İdeal olarak, herkes kodun en son sürümünü kontrol edebilmeli, testleri hemen uygulayabilmeli ve onaylarını görebilmelidir.
Başka şeylerdeki bağımlılıkları ortadan kaldırmak (dosya sistemi, veri tabanı, web servisleri, vb.) Konfigürasyona gerek duymamanızı sağlar ve sizi ve diğer geliştiricileri "Yapmadığım için testler başarısız oldu" demeye çalıştığınız durumlara daha az duyarlı hale getirir. ağ paylaşımını ayarlamamış. Ah, peki. Onları daha sonra çalıştıracağım. "
Bazı verilerle ne yaptığınızı test etmek istiyorsanız, ünitenizin o işletme mantık kodu için yaptığı testler, bu verileri nasıl aldığınızla ilgilenmemelidir . Uygulamanızın temel mantığını, veritabanları gibi destekleyici şeylere bağlı olmadan test edebilmek harika bir şey. Yapmıyorsan, kaçırıyorsun.
Not: Test edilebilirlik adına fazladan çalışmanın kesinlikle mümkün olduğunu eklemeliyim. Uygulamanızın test sürüşü bunu azaltmanıza yardımcı olur. Ancak, herhangi bir durumda, bir yaklaşımın kötü uygulamaları yaklaşımı daha az geçerli kılmaz. "Neden bunu yapıyorum?" Diye sormaya devam etmezse, her şey kötüye kullanılabilir ve fazla bırakılabilir. gelişirken.
İçsel bağımlılıklar söz konusu olduğunda işler biraz karışır. Düşünmeyi sevdiğim yol, sınıfımı yanlış nedenlerden dolayı değiştirmekten olabildiğince korumak istiyorum. Eğer böyle bir şey yapmazsam ...
public class MyClass
{
private SomeClass someClass;
public MyClass()
{
someClass = new SomeClass();
}
// use someClass in some way
}
Genelde nasıl SomeClassyaratıldığını umursamıyorum . Sadece kullanmak istiyorum. SomeClass değişiyorsa ve şimdi yapıcı için parametreler gerektiriyorsa ... sorun bu değil Buna uyum sağlamak için Sınıfımı değiştirmek zorunda kalmamalıyım.
Şimdi, bu sadece tasarım kısmına dokunuyor. Ünite testleri söz konusu olduğunda, kendimi diğer sınıflardan da korumak istiyorum. MyClass'ı test ediyorsam, dış bağımlılığın olmadığı gerçeğini bilmek isterim, SomeClass'ın bir noktada bir veritabanı bağlantısı veya başka bir harici bağlantı getirmediğini biliyorum.
Fakat daha da büyük bir sorun, bazı yöntemlerin sonuçlarının SomeClass'taki bazı yöntemlerden elde edilen çıktılara dayandığını da biliyorum. SomeClass'ı taklit / engellemeden, talep edilen girişi değiştirmek için hiçbir yolum olmayabilir. Şanslıysam, test ortamımdaki ortamımı SomeClass’tan gelen doğru cevabı tetikleyebilecek şekilde oluşturabilirim, ancak bu şekilde devam etmek testlerime karmaşıklığı getirir ve kırılgan hale getirir.
MyClass'ı yapıcıdaki bir SomeClass örneğini kabul edecek şekilde yeniden yazmak, istediğim değeri döndüren sahte bir SomeClass örneği oluşturmamı sağlıyor (alaycı bir çerçeveyle veya manuel bir alayla). Genellikle yok olması bu durumda bir arayüz tanıtmak. Bunu yapıp yapmamak, birçok yönden, tercih ettiğiniz dilin belirleyebileceği kişisel bir seçimdir (örneğin arayüzler C # 'da daha muhtemeldir, ancak kesinlikle Ruby'de bir taneye ihtiyacınız olmaz).