Saklı prosedürlerin birim testi

Bunu uzun zamandır düşünüyorum.

Temel soru şudur: saklı yordamlar nasıl test edilir?

Klasik anlamda fonksiyonlar için göreceli olarak kolay bir şekilde birim testleri ayarlayabildiğimi görüyorum (Demek istediğim, sıfır veya daha fazla argüman alıp bir değer döndürürler). Ancak, bir yere bir satır ekleyerek görünüşte basit bir prosedürün gerçek hayattan bir örneğini düşünürsem, birkaç tetikleyici ile bunu ve eklemeden önce veya sonra, bir 'ünitenin' sınırlarını tanımlamak bile oldukça zordur. Sadece INSERTkendini test etmeli miyim ? Bu oldukça basit, sanırım - nispeten düşük bir değere sahip. Tüm olaylar zincirinin sonucunu test etmeli miyim? Bunun bir birim testi olup olmadığı sorusunun yanı sıra, uygun bir test tasarlamak, yolda ortaya çıkan birçok soru işareti olan oldukça yorucu bir iş olabilir.

Ve sonra sürekli veri değiştirme sorunu geliyor. UPDATEBirkaç satırdan daha fazla etkileme durumunda, potansiyel olarak etkilenen her sıra test vakalarına bir şekilde dahil edilmelidir. DELETES ve benzeri şeylerle ilgili başka zorluklar .

Peki, saklı işlemlerinizi nasıl test edersiniz? Tamamen çaresiz kaldığı karmaşıklıkta bir eşik var mı? Bakım için hangi kaynaklar gereklidir?

EDIT AlexKuznetsov'un cevabını temel alan bir küçük soru daha: Yoksa altında tamamen yararsız olduğu bir eşik var mı?

Bunu neredeyse beş yıldır yapıyoruz ve açıkça yapılan değişiklik testlerinin kesinlikle yapılabilir olduğunu düşünüyoruz, ancak oldukça yavaş. Ayrıca, ayrı veritabanları kullanmadıkça, bu tür testleri birkaç bağlantıdan eşzamanlı olarak kolayca yapamıyoruz. Bunun yerine, değişiklikleri tam olarak test etmeliyiz - bunları test verilerinin en azından bir kısmını oluşturmak için kullanırız ve seçimlerimizin beklenen sonuçları getirdiğini doğrulayın.

Bu Loopholes'u Kapat başlıklı bir makale yazdım : Unit Testing T-SQL'den alınan dersler ve bazı blog gönderileri

Sorunuzla ilgili olarak "Tamamen umutsuzluğa kapıldığı karmaşıklıkta bir eşik var mı?", Karmaşık modüllerin basit olanlardan çok daha fazla teste ihtiyacı var.

Bakımı basitleştirmek için beklenen sonuçları üretiyoruz ve bunları ayrı dosyalarda saklıyoruz - bu büyük bir fark yaratıyor.

Evet, tüm olaylar zincirini bir birim olarak test etmelisiniz. Bu nedenle, örneğinizde bir tabloya yerleştirilen ve birkaç tetikleyicinin yanmasına neden olan bir prosedürle, çeşitli girdiler için prosedürü değerlendiren birim testleri yazmalısınız. Her birim testi, doğru değerleri döndürüp döndürmemesine, tabloların durumunu doğru değiştirmesine, doğru e-postayı oluşturmasına ve hatta eğer böyle bir şey için tasarlanmışsa doğru ağ paketlerini göndermesine bağlı olarak başarılı veya başarısız olmalıdır. Kısacası, her etkide ünite doğrulanmalıdır.

Haklısın, ünite testlerinin tasarlanması biraz çalışma gerektiriyor, ancak bu işin çoğunun üniteyi manuel olarak test etmesi gerekiyor, üniteyi test etmek için gereken işi saklıyorsunuz, böylece gelecekte bir değişiklik yapıldığında tam ve önemli ölçüde kolay olabilir.

Verileri değiştirmek testi daha zorlaştırır, ancak testi daha az önemli hale getirmez ve aslında birim testinin değerini artırır; zira çoğu zaman ünitede bir değişiklik yapılmak yerine zorlukların yalnızca bir kez düşünülmesi gerekir. Kaydedilen veri kümeleri, kurulum / parçalamanın bir parçası olan ekler / güncellemeler / silme işlemleri ve dar kapsamlı işlemlerin tümü bunu kolaylaştırmak için kullanılabilir. Soru veritabanına özgü olmadığı için, ayrıntılar değişecektir.

Sınamayı veya birim sınamasını engellemeniz gereken yüksek veya düşük uçta hiçbir karmaşıklık eşiği yoktur. Şu soruları göz önünde bulundurun:

1. Her zaman hatasız kod yazar mısın?
2. Küçük birimler her zaman hatasız mıdır?
3. Büyük bir birimin bir böceğinin olması doğru mudur?
4. Bir felakete neden olmak için kaç tane böcek gerekir?

Yeni bir işe başladığınızı ve birçok yerde kullanılan küçük bir işleve optimizasyon yapmakla görevlendirildiğini varsayalım. Başvurunun tamamı, kimsenin bile hatırlamadığı bir çalışan tarafından yazılmıştır. Birimler normal beklenen davranışı tanımlayan dokümantasyona sahiptir, fakat çok az. Bunlardan hangisini bulmayı tercih edersiniz?

• Uygulamada hiçbir yerde birim testi yapılmaz. Değişikliği yaptıktan sonra, dokümantasyonda beklenen değerleri döndürdüğünden emin olmak için ünitenin kendisine karşı bazı manuel testler yapabilirsiniz. Daha sonra onu üretime çıkarabilir, parmaklarınızı çapraz tutabilir ve çalışacağını umabilirsiniz (sonuçta, her zaman hatasız kod yazabilirsiniz ve bir ünitedeki bir optimizasyon hiçbir zaman bir başkasını etkilemez) veya tüm uygulamanın nasıl yapıldığını öğrenmek için büyük miktarda zaman harcayabilirsiniz. çalışır, böylece doğrudan veya dolaylı olarak etkilenen her birimi manuel olarak test edebilirsiniz.
• Uygulama boyunca otomatik olarak günlük veya talep üzerine çalışan birim testleri. Yalnızca normal giriş değerlerini ve beklenen yanıtlarını değil, aynı zamanda anormal değerleri ve ortaya çıkan beklenen istisnaları da kontrol ederler. Değişikliği yapıp, uygulama için ünite test takımını çalıştırıyorsunuz ve diğer üç ünitenin artık beklenen sonuçları getirmediğini görüyorsunuz. İkisi iyi huyludur, bu yüzden bunu hesaba katacak birim sınamalarını değiştirirsiniz. Üçüncüsü, başka bir ince ayar ve küçük bir yeni birim testi gerektirir. Değişiklikleri yaptıktan sonra tüm testler başarılı olur ve değişikliği güvenle tamamlarsınız.

PostgreSQL için pgTAP’a göz atın :

pgTAP, psql betiklerinde veya xUnit tarzı test işlevlerinde TAP yayıcı birim testleri yazmayı kolaylaştıran bir veritabanı işlevi paketidir.

Saklı yordamlar üzerinde yapılan testlerin tamamen SQL üzerinden yapılmasını tercih ediyorsanız, http://tsqlt.org/ adresine bakınız.

MS SQL 2005 SP2 ve üstü ile uyumludur ve avantaj, geliştiricilerin testleri uygulamak için C # veya başka bir dil bilmeleri gerekmez.

Yeniden çalıştırılabilir bir test takımı elde etmenize yardımcı olacak sahte masalar ve görünümler yapma olanakları da bulunmaktadır.