ETL'ler ve raporlama projeleri için TDD yöntemlerini nasıl test edersiniz?


12

ETL projeleri, SSIS, PowerCenter vb. Gibi bir ETL (Extract - Transform - Load) aracı kullanılarak oluşturulan projelerdir.

Bunlar genellikle harici bir kaynaktan veri okumayı, bir hazırlama veritabanına yüklemeyi, belirli dönüşümleri gerçekleştirmeyi ve bir son veritabanına yüklemeyi içerir

Basit bir örnek, SSIS kullanarak okul öğretmenleri tarafından sağlanan excel dosyalarını okumak ve bir veritabanına yüklemek için SSIS kullanmak olabilir. Ardından, her öğrencinin notlarını hesaplamak için saklı yordamlar veya daha fazla SSIS paketi yazın ve bu verileri bir veri deposuna yükleyin

Daha sonra görselleştirme oluşturmak için raporlama araçları (SSRS \ Excel \ etc) tarafından kullanılan çıktıyı oluşturmak için mart'ın üzerine saklı yordamlar oluşturun.

Bu senaryoda TDD ve uygun birim sınama nasıl anlamaya çalışıyorum. ETL'ler için yapılan testler çoğunlukla hazırlama tablolarına yüklenen verilerin kaynaktan gelen verilerin doğru alt kümesi olmasını sağlamakla ilgilidir. Bu nedenle, bunun için bir test uygulamak, ETL'nin mini bir versiyonunun uygulanmasına yol açar. Rapor SP'lerinin çıktısı tablolardaki verilere bağlıdır, bu nedenle temizlenmiş test verileri içeren bir veritabanı oluştursanız bile, bakım kabusu olmadan kararlı bir çıktı verisi kümesi olamaz.

Misal:

Sprint 1: Öğrenci tablosu Ad, Yaş, Not içerir

Bu tablo için test verileri ve buna dayalı birim testleri oluşturursunuz

Sprint 2: Tabloya bir cinsiyet alanı eklenir.

Şimdi, öğrenci alanındaki verileri cinsiyet özelliğini doldurmak için yenilerseniz, veriler değiştiği için test senaryoları geçersiz kılınır. Ve eğer yapmazsanız, cinsiyet sütununu gerektiren test senaryoları oluşturamazsınız


Test ettiğiniz araç zaten mevcutsa TDD değildir. Sadece sıradan testler yaz.
Robert Harvey

@RobertHarvey Aslında CTL kodu yazarken ETL aracı .Net Framework'ten farklı değil mi? Yani, aracı Net bir çerçeve var aynı şekilde var, henüz C # içinde TDD yapabilirsiniz
user87166

Framework yöntemlerini de test etmem. Sanırım zaten çalışıyorlar. Bir ETL aracı için bir yapılandırmayı test ediyorsanız, bunu yapmak için ETL aracında mantığı yeniden oluşturmanız gerekmez; sadece aracı kullanın.
Robert Harvey

1
Ardından, ETL'den, önerilen verilerden ve önerilen yapılandırmadan almayı beklediğiniz beklentileri kullanarak testleri yazın. İsterseniz bunları kavramsal testler yapın, ancak işlevsellik zaten var. Saf "önce test" gelişimi henüz var olmayan şeyler içindir. Ne yaparsanız yapın, ETL aracını yeniden icat etmeyin!
Robert Harvey

2
"Temel verilerdeki yaş değiştiği için" - girdi olarak kararlı test verilerinin sağlanması konusunda bu kadar zor olan ne ? Zamana bağlı hesaplamalar varsa, referans zamanlayıcıyı alay edin.
Doc Brown

Yanıtlar:


2

Geçmişte yaptığım şey Kabul Testine Dayalı Geliştirme kullanmaktır . ETL kodu genellikle farklı aşamalara / dillere ve teknolojilere dağıtılır VE sıkıca bağlanır. Çoğu ETL işlemi boru hattındaki dönüşümlerin sırasına bağlıdır.

Birim testini sadece ETL'de kullanma riski, entegrasyonları kapsamamasıdır. Dönüşümlerin dizilimi, birçok ETL'deki gerçek dönüşümlere eşittir. Otomatik bir test paketi oluşturmak için kaynak harcıyorsam, bu diziyi de kapsadığından emin olurdum.

Her benzersiz dönüşüm dizisi için TDD'ye odaklanacağım veya en azından bu testleri daha büyük bir test paketine dahil edeceğim. Çok fazla kombinasyon varsa, test edilecek dizileri seçip seçmeniz gerekebilir. Fikir, üzerinde kullanılacağı veri kümeleri için ETL boru hattını doğrulamaktır. Ayrıca tüm kodlarınız üzerinde test kapsamı olduğundan emin olun.


0

ETL, TDD ile yapılabilir ve çoğu projeye oldukça benzer testler, yani

başarısız olan bir test yazın (kırmızı) hatayı düzeltin (yeşil) kod performansını ve bakımını sağlayın (refactor)

ETL için şunlar olabilir:

  • 1 kayıt yüklemek için bir komut dosyası yaz
  • başarısız (tanımlanmış veri kaynağı yok)
  • kaynağı tanımla [yeşil]
  • refactor gerek yok
  • sadece 1 alan doldurulmuş olarak 1 kayıt yüklemek için bir test yazın
  • başarısız (bu alan için kod yazılmadı)
  • o alan için kod ayrıntılarını tanımlayın
  • refactor
  • geçerli değerlere sahip özellikleri arayan başarısız testleri tanımlayın [kırmızı]
  • vb

İlk 8 adımın TDD ile hiçbir ilgisi yoktur, çünkü hiçbir testi geride bırakmazlar. Gerisi belli değil.
Bulat
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.