Şu anda bir dosya sisteminin içeriğine dayalı bir tablo (diğer şeylerin yanı sıra) üreten bir proje üzerinde çalışıyorum ve sırayla bulduğu şeyler üzerinde bazı meta veri değişiklikleri yapar. Soru şudur: Testler bunun etrafında nasıl yazılmalı veya oluşturulmalıdır? Bunu yapmanın kolay bir yolu var mı? Yoksa bir "korumalı alan" oluşturmalı mıyım?
Yanıtlar:
TDD'de her zaman dış kaynaklarla yaptığınız gibi: dosya sistemi işlemleriniz için bir veya daha fazla arabirim oluşturur ve "bunları alay eder". Dosya sistemi işlemlerinin kendisini değil, "tablo oluşturucunuzu" ve meta veri değiştirme kodunuzu test etmek istiyorsunuz (büyük olasılıkla dosya sistemine erişmek için hazır kütüphane uygulamalarını kullanıyorsunuz).
"Test" dosya sistemine sahip olmanın nesi yanlış?
İşlemlerinizi test etmek için yeterli içeriğe sahip bir şablon klasörü / dizin yapısı oluşturun.
Ünite testinizin kurulumu sırasında bu ilk yapıyı kopyalayın (şablonu ZIP olarak eklemenizi ve test alanınıza çıkartmanızı önerir). Testlerinizi yapın. Yırtma sırasında her şeyi silin.
Mocking ile ilgili sorun öncelikle projenize ait dosya sistemleri, işletim sistemleri ve veritabanlarının gerçekten dış kaynak olarak nitelendirilmemesi ve ikinci olarak düşük seviyeli sistem çağrılarının alay edilmesinin hem zaman alıcı hem de hataya yatkın olmasıdır.
Gerçek dünya dosya sistemleri her türlü garip davranışa sahip olduğundan, bu kesinlikle entegrasyon testine ihtiyacınız olan tür bir şeydir (silme de dahil olmak üzere herhangi bir işlem açıksa Windows'un bir dosyayı silmeye izin vermemesi gibi).
Bu yüzden TDD yaklaşımı önce entegrasyon testini yazmaktır (TDD, kesinlikle konuşursak, 'birim test' ve 'entegrasyon testi' gibi farklı kavramlara sahip değildir; bunlar sadece testlerdir). Büyük olasılıkla bu yeterli olacaktır; böylece işi, durak, eve gitmek .
Değilse, dosyaları düzenleyerek yeterince sınanması kolay olmayan bir iç karmaşıklık olacaktır. Bu durumda, bu karmaşıklığı çıkarın, bir sınıfa koyun ve o sınıf için birim testleri yazın . Büyük olasılıkla bu ortak sınıfın veritabanı, xml dosyası vb. Durumlarda da kullanılabilir olduğunu göreceksiniz.
Hiçbir durumda, yazdığınız kodun temel çekirdeğini almaz ve test edilen ünitenin yanlış olup olmadığını geçecek testleri yazmak için 'taklit edemezsiniz'.
'unit test' and 'integration test'; they are just tests.bence gerçekçi, bu benim durumum için en iyi çözüm olacak - kenar durumlarda kullandığım dosya sistemi kitaplıklarını ve uygulamanın nasıl yanıt vermesi gerektiğini gerçekten test etmem gerekiyor şunlar. Farklı bir dosya sistemi kitaplığına geçersem, bir grup sahte / test kodunu yeni kitaplıkla çalışmak için yeniden yazmak zorunda kalmam, ancak bir test klasörü yapısına ve entegrasyon testlerine sahip olmak çok daha kolay olur.
Sorunuzu "Dosya sistemi işlemlerine bağlı bir sınıfı test etmenin iyi / kabul gören bir yolu" olarak anlıyorum. İşletim sisteminizin dosya sistemini test etmek istediğinizi düşünmüyorum.
@Doc Brown yanıtı olabildiğince küçük olarak önerilen 'dosya sistemi işlemlerinizle arayüzler oluşturmak ve "onları alay etmek" için çaba sarf etmek için java ikili akışları veya metin okuyucu (veya c # veya eşdeğeri) kullanmak iyi bir fikirdir. tdd tarafından geliştirilen sınıfta dosya adlarına sahip Dosyaları doğrudan kullanmak yerine ) .
Misal:
Java kullanarak bir sınıf CsvReader uyguladık
public class CsvReader {
private Reader reader;
public CsvReader(Reader reader) {
this.reader = reader;
}
}
Test için böyle bellek verilerinde kullandım
String contentOfCsv = "TestColumn1;TestColumn2\n"+
"value1;value2\n";
CsvReader sut = new CsvReader(java.io.StringReader(contentOfCsv));
veya test verilerini kaynaklara dahil edin
CsvReader sut = new CsvReader(getClass().getResourceAsStream("/data.csv"));
Üretimde dosya sistemini kullanıyorum
CsvReader sut = new CsvReader(new BufferedReader( new FileReader( "/import/Prices.csv" ) ));
Bu şekilde CsvReader'ım dosya sistemine değil, dosya sistemi için bir uygulamanın olduğu bir soyutlama "Okuyucu" ne bağlıdır.