SQL ve veri işleme işlevli TDD

Profesyonel bir programcı olduğum halde hiçbir zaman yazılım mühendisliği eğitimi almadım. Burada sık sık ziyaret ettiğimden ve SO olarak, mümkün olduğunca birim testleri yazma eğilimi fark ettim ve yazılımım daha karmaşık ve sofistike olduğundan, otomatik testi hata ayıklamaya yardımcı olmak için iyi bir fikir olarak görüyorum.

Ancak, işlerimin çoğu karmaşık SQL yazmayı ve sonra çıktıyı bir şekilde işlemeyi içeriyor. Örneğin, SQL'inizin doğru verileri döndürdüğünden emin olmak için nasıl bir test yazardınız? Daha sonra, verilerin kontrolünüz altında değilse (örneğin, bir üçüncü taraf sistemininki gibi), kukla verilerin topaklarını elle yazmak zorunda kalmadan işleme rutinlerinizi nasıl etkili bir şekilde test edebilirsiniz?

Düşünebileceğim en iyi çözüm, birlikte, çoğu durumu kapsayan verilerin görünümlerini oluşturmaktır. Daha sonra doğru kayıtları döndürüp döndürmediğini görmek için bu görünümleri SQL'imle birleştirebilirim ve işlevlerimin vb. Olması gerekeni yapıp yapmadığını görmek için görünümleri elle işleyebilirim. Yine de, aşırı ve pul pul gibi görünüyor; özellikle test edilecek verileri bulma ...

Veritabanı ile ilgili her şeyi test etmek için önemli bir kural, onu uygulamanızın geri kalanından tamamen izole etmektir.

Bağlantı noktaları ve adaptörler mimarisi gerçekten iyi bir örnektir. Veritabanı, uygulamanıza bir adaptör aracılığıyla harici bir eklenti olarak kabul edilir. Aynı şey tüm 3. taraf alt sistemleri için de geçerlidir. Uygulamanızın nasıl davranacağını ve üçüncü taraf alt sistemlerinin yanıtlarını nasıl yorumlayacağını test etmek için, bu bağımsız alt sistemin yanıtlarını saptamak için nasıl test edeceğimizi bilmemin tek yolu. Mutlaka tüm veri nesnelerini manuel olarak yazmak zorunda kalacağınız anlamına gelmez. Veri odaklı test kullanma yaklaşımını kolayca kullanabilirsiniz.

Uygulamanızın veritabanınızla nasıl etkileşime girdiğini sınama konusunda, örneğin bir bellek içi veritabanı kullanmak için veritabanı bağdaştırıcılarını taklit edebilirsiniz.

Şimdi veritabanı sorgularınızı test edin. Her şeyden önce, karmaşık sorgular daha kolay, basit ve tahmin edilebilir sorgularda ayrıştırılmalıdır. Bir yağ sınıfı veya bir yağ fonksiyonu için yapacağınız gibi. Veritabanınızı Dbunit gibi test etmenize yardımcı olabilecek araçlar var. Bazen aldığım basit bir yaklaşım, karakterizasyon testleri kavramını kullanmaktır. Bu yüzden veritabanı biliyorum bir durumda koymak, yazmak zorunda tüm sorguları çalıştırmak bir yerde (dosya, bellek) çıktı kaydetmek ve bu çıktı doğru olanı düşünün. Sonraki çalışmalar bu çıktı ile karşılaştırmak, bu yüzden kesinlikle bana ihtiyacım olan regresyon testi sunacak. Gerçekten de ilk çıktının doğru olduğu garanti edilmez, ancak regresyon problemi bu şekilde çözülebilir. Sorgularınız iyi ayrıştırılmışsa, bunları bilinen bir durumdaki veritabanına göre ayrı ayrı test edebilirsiniz.

Bu ilginç bir sorudur çünkü veritabanı genellikle uygulama birimi testi sırasında taklit edilen kısımdır. Umarım veritabanı motorunun kendisinin mantığı, sağlayıcı tarafından iyi bir şekilde test edilir, ancak tabii ki sorgular, şema ve saklı prosedürler, test edilmesi ve regresyona karşı korunması gereken kodlardır. Bu genellikle TDD olmayan entegrasyon testine bırakılır.

Görüşler bunu yapmanın zor bir yolu olacaktır çünkü testte TDD'de tercih edilen her test için bir yönün ilk kırmızı ışık, yeşil ışık otomatik testine borç vermezler. Ayrıca görünümlerde, testi koddan önce yazamazsınız. Daha iyi bir yaklaşım, çıktıda hata olup olmadığını sınamak için yordama "assert" mantığı ekleyebileceğiniz saklı yordamlar yazmak olacaktır (örneğin, "if" ifadelerini kullanarak). Üniteyi izole etmek için her ünite testinde sadece bir şeyi test etmeniz gerekir ve SP yöntemi bunun için daha uygundur. Ayrıca, SP'lerle, ilk kodu geliştirirken ve daha sonra yeniden düzenleme yaparken gerilemeleri test ederken tüm paketlerini komut dosyası olarak çalıştırabilirsiniz.

Ayrıca, testlerin tekrarlanabilir olması gerektiğine dikkat edin ve her birim testi için durumun aynı olduğundan emin olmak için veritabanı durumunu başlatmak ve yırtmak için bazı komut dosyalarına ihtiyacınız olacaktır.

Kontrolünüz altında olmayan veriler hakkındaki sorunuz için bu zor bir alandır. Sahte verilerle alay etmenin ve ünite testleri için istisna ve kenar koşullarını mümkün olduğunca test etmenin daha iyi olduğunu düşünüyorum. Aksi takdirde entegrasyon testi kategorisine girecektir (bu da yapılması iyi bir şeydir). Entegrasyon testi için testlerinizi 3. taraf verilerine karşı çalıştırabilir ve bir ilk çıktı üretmesine izin verebilir ve sonraki testler için (örn. Yeniden düzenleme işleminden sonra), bu çıktıların bilinen ilk çıktıyı tekrarladığından emin olun.

Bir noktada test verilerine ihtiyacınız olacak. 3. taraf bir sistem kullanıyorsanız, şema zaten oluşturulmuştur, ancak gelecekteki değişiklikleri ele almanız gerekir. Umarım, bu değişiklikleri yükseltme belgelerinden alabilirsiniz, ancak veritabanı sürümlerini kendiniz karşılaştırmak zorunda kalabilirsiniz.

Beklenen sonuç kümeleri veritabanı tablolarına veya harici dosyalara / elektronik tablolara kaydedilebilir. Ben bile CHECKSUM kullanılmış veya karşılaştırma gördüm. Bir görünümü / sproc'u test ettiğinizde, var olmadıkları için bir hata alırsınız. Daha sonra nesneyi en azından yürütmek için yeterli kodla oluşturursunuz (SELECT -1 as [false_data];) ve sonuç kümesiyle eşleşmediği için bir hata alırsınız. Eşleştikten sonra yeşil ışığa sahip olursunuz.

Proje sahipleriyle çalışmaya başladım ve bir e-tablodaki raporları alay etmelerini ve kısmi veriler benim için gelmelerini istedim (Sonuç verilerini bir test tablosuna koyabilirsiniz.). İlk başta bir itiraz vardı, ama bir rapor oluşturacağımı fark ettiler ve yine de doğrulamak zorunda kalacaklar. Bu uzun vadede zaman kazandırdı. Değişiklik isteği yapmak istiyorlarsa, e-tabloyu yeniden yapabilirler. Şimdi "Eklemek ne kadar zor olurdu ...?"

Veritabanı platformunuz SQL Server ise, çok güzel bir ücretsiz araç vardır: tSQLt .

tSQLt, Microsoft SQL Server için bir veritabanı birimi test çerçevesidir. tSQLt, tüm sürümlerde SQL Server 2005 (service pack 2 gereklidir) ve üstü ile uyumludur.

Veritabanı düzeyinde test uygulamak için başarılı bir şekilde kullandım.

Bu kadar kullanışlı kılan temel unsurlardan bazıları şunlardır:

• İlgili kurulumu normalleştiren sahte tablolar ve görünümlerle çalışma yeteneği
• Testler işlemlerde otomatik olarak gerçekleştirilir (bu nedenle kolayca yeniden çalıştırılabilir)
• Ekleriniz tablolarda (hem gerçek hem de sahte) karşılaştırmalar yapabilir, böylece herhangi bir veriyi kolayca değiştirip değiştirmediğinizi görebilirsiniz