Witajcie,
Mój problem dotyczy koncepcji testowania aplikacji.
Mam kontroler “UserController” oraz model User.
Praktycznie wszystkie akcje na modelu User (create,update, save itd) sa wykonywane przez kontroller. Wszystkie te akcje “obtestowałe” w UserControllerTest.
Miałem przystąpić do pisania testów modelu (Unit) i uświadomiłem sobie że w zasadzie powtarzam te same funkcje które testowalem w kontrolerze. Np.:
post :newuser :user => {:name => "bb"}
i tak wykonuje w efekcie User.create ktory sprawdzam w kontrollerze (moze tu jest błąd?). Zastanawiam sie zatem czy sensowne jest powtarzanie testow tych operacji w testach modelu ?
To by przeczylo DRY.
Jak, Waszym zdaniem, należało by podejść do tego tematu ?
Narazie moja (chora i niezgodna z DRY) recepta to powtarzanie testu w kontrolerze i modelu.
Przyznam sie, ze jestem troche na bakier z testowaniem
Unit testy - Model testowany jest w izolacji od aplikacji. Test taki moze dotyczyc wszystkich aspektow danego modelu, kt. moga byc rozrzucone w roznych kontrolerach.
Testy funkcjonalne - Kontroler z kolei moze polegac na wielu modelach czy innych klasach(*) w danej testowanej funkcjonalnosci jak rowniez wykorzystywac tylko podzbior funkcjonalnosci jednego modelu.
Invalidacja cache przy insert/update, czy jakies operacje na dysku towarzyszace wstawianiu rekordu - jezeli te operacje calkowicie enkapsuluje model to nie sadze aby wiekszym sensem bylo tworzenie testow funkcjonalnych.
I owszem czesc rzeczy bedzie sie pokrywac, Ale nie sadze zeby zasada DRY odnosila sie do testow. Zwlaszcza, ze testy modelu sa w oderwaniu od aplikacji.
IMHO nie nalezy przesadzac.
Testowanie rzeczy oczywistych nie ma wiekszego sensu, test suite rosnie bez wiekszych korzysci dla aplikacji.
[quote=pawel]IMHO nie nalezy przesadzac.
Testowanie rzeczy oczywistych nie ma wiekszego sensu, test suite rosnie bez wiekszych korzysci dla aplikacji.[/quote]
Tutaj sie troche nie zgodze. Moim zdaniem nawet trywialne testy w stylu co sie stanie jak wpisze cene jako “99.00” i “99,00” potrafia ulatwic zycie supportowi
Oczywiscie to kwestia indywidualna co testowac i jak
O tego typu sprawy powinna dbac walidacja i konwertery. W ten sposob nalezaloby pisac testy co sie stanie jak ktos wprowadzi tak: 1,234.21 (czyli prawidlowy format ale nie w Polsce) albo 12…5 itd. Najprosciej zamienic wszystkie ewent. ‘,’ na ‘.’ ale to nie wyjscie. W javie jest klasa DecimalFormat, kt. parsuje stringi wg. danej lokalizacji i jak RoR dorobi sie i18n to pewnie tez tak bedzie.
Ruby czyli tez RoR ma niebywale skopany (tzn. w ogole nie ma) UTF-8 i jak tylko przekazuje stringi z/do bazy to jest ok, ale przy reg. exp. zaczynaja sie schody. Dodatkowo jako jezyk interpretowany trzeba zwracac uwage na strone kodowa pliku. Oczywiscie dotyczy to diakrytykow. Tutaj nie podarowalbym sobie testu. Nawiasem mowiac zastanawialem sie czy 8859-2 nie zaczac uzywac przez to.
Potestowalbym sobie tez np. jak dziala optymistic lock i kwestie wstawiania w kolekcje.
Z drugiej strony, jestem skazony java, gdzie wiele rzeczy nie przejdzie kompilacji. W ruby pewne sprawy widac dopiero w runtime wiec na pewno nawet trywialne sprawy nie zaszkodzi sprawdzic
[quote=pawel]Oczywiscie to kwestia indywidualna co testowac i jak
Z drugiej strony, jestem skazony java, gdzie wiele rzeczy nie przejdzie kompilacji. W ruby pewne sprawy widac dopiero w runtime wiec na pewno nawet trywialne sprawy nie zaszkodzi sprawdzic[/quote]
Przy kompilacji chociazby Ci sie wywali niezgodnosc typow, a w RoR zobaczysz fajnego exception na stronie
