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?
Odpowiedzi:
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.
źródło
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.
źródło
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.
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).
źródło