TDD do przetwarzania wsadowego: jak to zrobić?

Lubię „czerwony / zielony / refaktor” dla RoR itp. W porządku.

Moja codzienna praca polega na przetwarzaniu wsadowym bardzo dużych plików stron trzecich w Pythonie i innych niestandardowych narzędziach.

Rezygnacja z atrybutów tych plików jest wysoka, więc często stosuje się wiele poprawek / ulepszeń.

Testowanie regresyjne za pomocą znanego zbioru danych testowych z oczekiwanymi wynikami nie istnieje. Najbliższa rzecz działa przeciwko ostatniej partii z nowymi ręcznie zakodowanymi przypadkami testowymi, upewnij się, że się nie wysadzi, a następnie zastosuj kontrolę punktową i testy statystyczne, aby sprawdzić, czy dane nadal wyglądają OK.

P >> Jak wprowadzić zasady TDD do tego rodzaju środowiska?

Tylko informacja: Testy jednostkowe nie są równoważne TDD. TDD to proces, którego elementem jest test jednostkowy.

Powiedziawszy to, jeśli chcesz wdrożyć testowanie jednostkowe, możesz zrobić wiele rzeczy:

Wszystkie nowe kody / rozszerzenia są testowane

W ten sposób nie musisz przechodzić i testować jednostkowo wszystkiego, co już istnieje, więc początkowy garb wdrożenia testów jednostkowych jest znacznie mniejszy.

Przetestuj poszczególne fragmenty danych

Testowanie czegoś, co może zawierać duże ilości danych, może prowadzić do wielu przypadków brzegowych i luk w zasięgu testu. Zamiast tego rozważ opcję 0, 1, wiele. Przetestuj „partię” z 0 elementami, 1 elementem i wieloma elementami. W przypadku 1 elementu przetestuj różne kombinacje, w których mogą znajdować się dane dla tego elementu.

Następnie przetestuj przypadki krawędzi (górne granice wielkości poszczególnych elementów i ilości elementów w partii). Jeśli regularnie przeprowadzasz testy i masz długie testy (duże partie?), Większość testerów pozwala na kategoryzację, dzięki czemu możesz uruchamiać te przypadki oddzielnie (co noc?).

To powinno dać ci silną bazę.

Korzystanie z rzeczywistych danych

Wprowadzanie „rzeczywistych” wcześniej używanych danych, tak jak teraz, nie jest złym pomysłem. Po prostu uzupełnij go dobrze sformułowanymi danymi testowymi, aby natychmiast poznać konkretne punkty awarii. W przypadku braku obsługi rzeczywistych danych można sprawdzić wyniki procesu wsadowego, wykonać test jednostkowy w celu odtworzenia błędu, a następnie powrócić do czerwonego / zielonego / refaktora z przydatnymi przypadkami regresji.

Jest taki sam jak w każdym innym środowisku.

Podziel logikę na najmniejszy poziom szczegółowości. To da ci zestaw reguł dla procesu, każda reguła obejmie jeden element logiki wymagany dla twojego procesu.

Następnie napisz test dla każdej reguły. Te testy zakończą się niepowodzeniem. Napisz kod, aby naprawić test.

Testowanie regresyjne ze znanymi danymi testowymi, o których mówisz, nie jest testowaniem jednostkowym. To byłyby testy integracyjne, różni się to od TDD. Z TDD możesz mieć jeden test, aby przetestować, czy możesz załadować plik, ale generalnie żaden inny test nie byłby w pobliżu pliku danych z danymi testowymi. Zamiast tego symulowałbyś dane wymagane do wykonania określonej reguły przy użyciu obiektu kpiącego.

Zacznij od dobrej strategii oprogramowania, a następnie zastosuj TDD.

(Oświadczenie: mogłem źle zrozumieć „churn”, TDD lub oba.)

Oto moja sugerowana strategia przetwarzania wsadowego „brudnych danych”: Specify-Triage-Execute.

• Opracuj specyfikację danych w sposób ścisły i wąski, ale obejmie większość (powiedzmy 80% lub więcej) danych przychodzących. Nazwij tę specyfikację 1 .
• Opracuj moduł Triage (TDD, jeśli chcesz), który decyduje, czy rekord spełnia specyfikację 1.
  • Upewnij się, że moduł działa bardzo szybko.
  • Moduł powinien zwracać wartość prawda / fałsz: albo spełnia wszystkie reguły, albo nie.
• Opracuj moduł Wykonaj (TDD, jeśli chcesz), który analizuje rekord, o którym wiadomo, że spełnia specyfikację 1, wykonując zadania wymagane przez klientów.
• Zastosuj Triage 1 do wszystkich przychodzących danych.
  • Wynikiem jest jedna wartość logiczna dla każdego rekordu. Zasadniczo dzieli dane przychodzące na: Specyfikacja 1 lub Nieznany.
  • Zastosuj Wykonaj 1 dla danych Specyfikacji 1, ilekroć klient tego potrzebuje.
• Rozluźnij zasady specyfikacji 1, aby przyjąć 80% pozostałych danych. Nazwij tę specyfikację 2 .
• Opracuj Triage 2 i Wykonaj 2 . Zastosuj go do danych, które nie spełniają specyfikacji 1.
• Powtarzaj tę samą liczbę poziomów, ile potrzeba, aż pozostałe dane będą na tyle małe, że można je ręcznie przetwarzać codziennie.

Smakołyk wydajności:

Zapisz wszystkie wyniki Triage (historyczne lub bieżące) związane z rekordem. Jeśli żaden moduł Triage nie został zmodyfikowany od ostatniego uruchomienia, nie trzeba go ponownie uruchamiać na starych danych.

„Musisz wiedzieć, co chcesz zbudować przed zrobieniem TDD”:

Specify-Triage-Execute to jeden ze sposobów utrzymania wymagań w zakresie zarządzania na każdym poziomie i pozwala na przyszły rozwój.

(Jeśli ktoś zna standardowe poprawne warunki dla tych trzech kroków, daj mi znać, zmienię swoje odpowiedzi).