Jak testujesz jednostkę \ używasz metod TDD dla ETL i projektów sprawozdawczych?


12

Projekty ETL to projekty tworzone za pomocą narzędzia ETL (Extract - Transform - Load), takiego jak SSIS, PowerCenter itp.

Zazwyczaj obejmują one odczytywanie danych ze źródła zewnętrznego, ładowanie ich do tymczasowej bazy danych, wykonywanie pewnych transformacji i ładowanie do ostatecznej bazy danych

Prostym przykładem byłoby użycie SSIS do odczytu plików Excela dostarczanych przez nauczycieli korzystających z SSIS i załadowania ich do bazy danych. Następnie napisz procedury składowane lub więcej pakietów SSIS, aby obliczyć oceny każdego ucznia i załadować te dane do hurtowni danych

Następnie tworzysz procedury składowane na szczycie mart, aby wygenerować dane wyjściowe, które są używane przez narzędzia raportujące (SSRS \ Excel \ etc) do generowania wizualizacji.

Staram się zrozumieć, jak przeprowadzić TDD i odpowiednie testowanie jednostek w tym scenariuszu. Testy ETL polegają głównie na upewnieniu się, że dane załadowane w tabelach pomostowych pasują do właściwego podzbioru danych ze źródła. Tak więc wdrożenie testu prowadzi do wdrożenia mini-wersji ETL. Dane wyjściowe raportów SP zależą od danych w samych tabelach, więc nie można mieć stabilnego zestawu danych wyjściowych bez koszmaru konserwacji, nawet jeśli utworzysz bazę danych zawierającą oczyszczone dane testowe

Przykład:

Sprint 1: Tabela ucznia zawiera imię, wiek, klasę

Tworzysz dane testowe dla tej tabeli i na tej podstawie przeprowadzasz testy jednostkowe

Sprint 2: Pole płci jest dodawane do tabeli.

Teraz, jeśli odświeżysz dane w polu ucznia, aby wypełnić atrybut płci, przypadki testowe zostaną unieważnione, ponieważ dane się zmieniły. A jeśli nie, nie możesz tworzyć przypadków testowych, które wymagają kolumny płci


To nie TDD, jeśli testowane narzędzie już istnieje. Po prostu napisz zwykłe testy.
Robert Harvey,

@RobertHarvey W rzeczywistości narzędzie ETL nie różni się od .Net Framework podczas pisania kodu C #, prawda? Tak więc narzędzie istnieje w taki sam sposób, jak struktura .Net, ale możesz wykonywać TDD w C #
user87166

Nie testowałbym też metod Framework. Zakładam, że już działają. Jeśli testujesz konfigurację narzędzia ETL, nie musisz ponownie tworzyć logiki w narzędziu ETL; po prostu użyj narzędzia.
Robert Harvey,

1
Następnie napisz testy, używając oczekiwań, które oczekujesz od ETL, proponowanych danych i proponowanej konfiguracji. Zrób z nich testy koncepcyjne, jeśli chcesz, ale funkcjonalność już istnieje. Czysty rozwój „najpierw przetestuj” dotyczy rzeczy, które jeszcze nie istnieją. Cokolwiek robisz, nie wymyślaj na nowo narzędzia ETL!
Robert Harvey,

2
„odkąd zmienił się wiek danych podstawowych” - co jest takiego trudnego w dostarczaniu stabilnych danych testowych jako danych wejściowych? Jeśli w grę wchodzą obliczenia zależne od czasu, wyśmiewaj się z timera odniesienia.
Doc Brown,

Odpowiedzi:


2

W przeszłości robiłem test rozwoju oparty na testach akceptacyjnych . Kod ETL jest często dystrybuowany na różnych etapach / językach i technologiach ORAZ ściśle powiązany. Większość procesów ETL zależy od sekwencji transformacji w potoku.

Ryzyko użycia testu jednostkowego tylko w ETL polega na tym, że nie obejmie on integracji. Sekwencjonowanie transformacji jest równą częścią rzeczywistych transformacji w wielu ETL. Jeśli przeznaczam zasoby na tworzenie automatycznego zestawu testów, upewnię się, że obejmuje on również sekwencjonowanie.

Skoncentrowałbym się na TDD dla każdej unikalnej sekwencji transformacji lub przynajmniej uwzględniłbym te testy w większym zestawie testów. Jeśli jest zbyt wiele kombinacji, może być konieczne wybranie sekwencji do przetestowania. Pomysł polega na sprawdzeniu poprawności potoku ETL dla zestawów danych, w których będzie on używany. Oprócz upewnienia się, że masz zasięg testowy całego kodu.


0

ETL można wykonać za pomocą TDD i testów całkiem podobnych do większości projektów, tj

napisz test, który się nie powiedzie (czerwony) napraw błąd (zielony) uczyń kod wydajnym i łatwym do konserwacji (refaktoryzacja)

W przypadku ETL może to być:

  • napisz skrypt, aby załadować 1 rekord
  • fail (nie zdefiniowano źródła danych)
  • zdefiniuj źródło [zielony]
  • nie ma potrzeby refaktoryzacji
  • napisz test, aby załadować 1 rekord z wypełnionym tylko 1 polem
  • fail (nie napisano kodu dla tego pola)
  • zdefiniuj szczegóły kodu dla tego pola
  • refaktor
  • zdefiniuj testy zakończone niepowodzeniem, które szukają atrybutów o prawidłowych wartościach [czerwony]
  • itp

Pierwsze 8 kroków nie ma nic wspólnego z TDD, ponieważ nie pozostawiają żadnych testów. Reszta nie jest jasna.
Bulat
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.