Jak w temacie - co testujecie i jak?
Zastanawia mnie czy i jak testujecie kontrolery, widoki i testy integracyjne, oraz jak testujecie modele/własne klasy.
Ile średnio wynosi waże code ratio i code coverage?
Pozdrawiam!
Wydaje mi się że co do modeli, wątpliwości również są. Skoro jednak masz pewność to nie będę wprowadzał zamieszania.
Ja preferuję: Capybara + RSpec do acceptance, RSpec do modeli i innych testów jednostkowych, oraz testów funkcjonalnych niektórych kontrolerów (np. API). Jeśli masz dużo JavaScriptu, proponuję również Jasmine od testół jednostkowych klas JavaScriptu.
Właściwie to można i podyskutować na temat modeli, więc edytuję co napisałem wyżej ;p
Sam korzystam podobnie, rspec+capybara (modele, własne klasy i integracyjne, api kontrolerów), do js jasmine, nie testuję innych kontrolerów oraz widoków (nie widzę sensu, ale jeżeli ktoś ma na ten temat inne zdanie to chętnie usłyszę). Code ratio 1:1 - 1:1.5, code coverage ~90-95%.
ja używam mini test + capybara-webkit do wszystkiego.
Piszę testy jednostkowe do tego, co jest istotne w modelach(a nie wszystko jest istotne). Możliwie najmniej integracyjnych, i sporo funkcjonalnych.
Dawno temu(jakoś w okolicach tego, gdy zrozumiałem, że testowanie to jednak fajna sprawa 
) miałem taką fazę, że zacząłem testować wszystko code/test ratio wynosił coś w okolicach 4.2, i zmiana czegokolwiek w aplikacji trwała wieki, bo powodowało, że trzeba było przez kilka godzin poprawiać testy – w sumie całkiem ciekawe doświadczenie, bo dużo się wtedy nauczyłem, jednak teraz mam coś w okolicach 1:1.
[quote=krzyzak]ja używam mini test + capybara-webkit do wszystkiego.
Piszę testy jednostkowe do tego, co jest istotne w modelach(a nie wszystko jest istotne). Możliwie najmniej integracyjnych, i sporo funkcjonalnych.
Dawno temu(jakoś w okolicach tego, gdy zrozumiałem, że testowanie to jednak fajna sprawa ) miałem taką fazę, że zacząłem testować wszystko code/test ratio wynosił coś w okolicach 4.2, i zmiana czegokolwiek w aplikacji trwała wieki, bo powodowało, że trzeba było przez kilka godzin poprawiać testy – w sumie całkiem ciekawe doświadczenie, bo dużo się wtedy nauczyłem, jednak teraz mam coś w okolicach 1:1.[/quote]
Mam bardzo podobne doświadczenia. Ja np. prawie wcale nie piszę testów jednostkowych do kontrolerów i bardzo uważam na mockowanie. Generalnie mokuje tylko rzeczy, które na 90% nie będą się zmieniać w aplikacji (mają stabliny interfejs / API) i czasami jakies zewnętrzne biblioteki lub zewnętrzne serwisy za pomocą bardzo przydatnego gema VCR.
Testy do widoków to moim zdaniem jest totalną stratą czasu.
VCR, jakkolwiek niewątpliwie przydatny, to jednak nie mockuje niczego.
Zależy co masz w widokach. Jeśli to jest JSON, którym serwujesz do SPA, to warto testować czy API jest zachowane.
Pozwól, że się nie zgodzę - może nie umiem pisać widoków, ale zazwyczaj mam tak, że jest tam największe prawdopodobieństwo zrobienia bajzlu - w sensie takim, że wkładasz tam palucha, a rozwala się coś w innym miejscu. Dlatego staram się zawsze chociaż trochę testować widoki 
Poza tym widok to (najczęściej) Twoja interakcja z userem - czyli moim zdaniem jedna z ważniejszych części aplikacji.
Pozwól, że się nie zgodzę - może nie umiem pisać widoków, ale zazwyczaj mam tak, że jest tam największe prawdopodobieństwo zrobienia bajzlu - w sensie takim, że wkładasz tam palucha, a rozwala się coś w innym miejscu. Dlatego staram się zawsze chociaż trochę testować widoki
Poza tym widok to (najczęściej) Twoja interakcja z userem - czyli moim zdaniem jedna z ważniejszych części aplikacji.[/quote]
Jezeli twoje widoki to markup i wywolania pojedynczych metod to jest mala szansa ze cos sie zepsuje. Robert Martin tez nie testuje widokow dlatego ze sa tak proste. Wspomnial o tym pod koniec tego wykladu
http://www.confreaks.com/videos/759-rubymidwest2011-keynote-architecture-the-lost-years