Testy - rake task

Witajcie,

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 ?

Czas rzucic zle nawyki i zaczac pisac testy :slight_smile:

Pozdrowienia

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.

Tu jest http://blog.jayfields.com/2006/11/ruby-testing-rake-tasks.html przykład tego o czym pisze squil

Jak wyżej. A jak już chciałem testować coś z samego wykonania to kombinowałem tak: http://gist.github.com/487467

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.

W szczególności powinno się pisać testy dla błędnych danych no nie ?

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).