Jest masa tutoriali w sieci na temat pisania bloga w 5 minut, jest wiele informacji rowniez na temat pisania testow, nie znalazlem jednak zadnego sensownego tutoriala pokazujacego jak krok po kroku i czym testowac kod.
Stoje przed koniecznoscia napisania task’a, ktory pobierze cos z zewnetrznej bazy (cztery tabele), scali to i wrzuci do dwoch tabel w lokalnej bazie danych.
Proces tworzenia tego tasku chcialbym wykonac tak jak nalezy, czyli z wlasciwymi testami.
Jak sie do tego zabrac ? Z czego najlepiej skorzystac ?
Rake taska nie przetestujesz. Najlepszą metodą jest wyrzucić co tylko się da do zewnętrznej klasy/modułu i przetestować tę klasę/moduł. Osobiście do testowania używam RSpeca.
Generalnie problem, przed którym stoisz jest kiepsko testowalny. O ile dobrze rozumiem chodzi Ci o coś z gatunku ETL (extract, transform, load).
Dlaczego? Bo dane w testach mają się nijak do danych, które faktycznie będą w bazie danych. W szczególności w źródłowej bazie mogą być dane błędne, a przecież nie pisze się testów dla błędnych danych.
To co sam stosuję w tego typu przypadkach, to duża ilość statycznych (tzn. validates_…) i dynamicznych (łażących po relacjach i sprawdzających czy wszystko się domyka jak należy) walidacji. Spowalnia to znacznie proces, ale pozwala wykryć wiele błędów, albo przynajmniej uświadomić je sobie.
Ok, wyraziłem się nieprecyzyjnie - jasne, tyle, że w normalnym przypadku dla tych danych system powinien zgłaszać błąd i to powinno być testowane. Natomiast przy ETL te dane mimo wszystko powinny być uwzględnione i (najczęściej) zassane do bazy.
EDIT
Chodzi mi o taką sytuację, w której powiedzmy walidujemy PESEL. Sensowny test dla wadliwego PESELu powinien sprawdzać, czy sygnalizowany jest błąd. Natomiast przy ETL nie możemy sobie pozwolić na to, żeby te dane zostały pominięte - więc musimy zassać również “błędne” dane, bo w przeciwnym razie utracilibyśmy część z nich. No i tutaj grzebana jest cała idea testowania - faktyczny “test” realizowany jest zawsze dla tych danych, które podlegają eksportowi i niezależnie co jest poprawne/niepoprawne w teorii, w praktyce i tak trzeba dużo rzeczy zmodyfikować (wbrew TDD).