OpenSource'owy wzór

Witam,

Zastanawiam się czy natrafiliście na jakiś projekt opensource w railsach, który polecilibyście jako wzór do naśladowania. W sesnie, że wszystko (lub prawie) jest zrobione tak jak powinno. Czysty kod, odpowiednie wykorzystanie danych funkcjonalności frameworka, czytelnie napisane testy itd. Oczywiście, to trochę kwestia gustu, więc nie każdy musi się zgadzać z daną propozycją, ale myśle że ciekawie byłoby poznać taką listę w razie jakby ktoś chciał poczytać dobry kod.

Jeżeli coś podajecie to fajnie by było uzasadnić dlaczego dany projekt itd :slight_smile:

Dzięki.

PS. Możliwe że taki (lub podobny) temat był, ale nie udało mi się znaleźć, więc w razie czego przepraszam i proszę o przekierowanie :slight_smile:

to ja powiem że teambox

dlaczego?

ładny kod
testy w cucumberze (również do funkcjonalne do javascriptów)
wykorzystuje wszystkie ważne moduły railsowe
udostępnia zewnętrzne API
fajnie się tego używa :slight_smile:
można odpalić na chmurze amazona
haml i sass
aktywnie rozwijany(ostatni commit - wczoraj)
dochodowy(przynajmniej tak twierdzą)
korzysta z ważnych(moim zdaniem) i popularnych gemów takich jak:
-cancan
-paperclip
-sphinx
-whenever
-icalendar
-hpricot
jak piszesz w railsach to prędzej czy później zetkniesz się z nimi

prototype (wole jQuery ale co poradze :P)
licencja GNU

EDIT

link:

Fajnie gdyby takie projekty były oparte na Rails 3.0 :slight_smile:

Chętnie bym powiedizał że któryś z projektów na moim koncie na githubie… ale to nie prawda ;).

A tak serio: nie ma takiego projektu. To co jest idealne dla jednego, dla drugiego może być nie do zaakceptowania…

[quote=phocke]to ja powiem że teambox

ładny kod
testy w cucumberze (również do funkcjonalne do javascriptów)[/quote]
To fajny projekt, na pewno warto przejrzeć i wiele można się nauczyć.

Ale muszę czepnąć się testów. Co z tego, że w ruch idzie Cucumber, jeśli nawet modele nie są przetestowane. Cześć nie ma w ogóle testów, w pozostałych testy są mniej więcej wielkości kodu, co jest podejrzane, bo kompletne testy zajmują z reguły wyraźnie więcej niż testowany kod, ok 1.3-2x więcej.


http://qertoip.typepad.com - Clojure, Rails, i swetrowe sprawy.

Nie potrzebnie się czepiasz :slight_smile:

Cucumber testuje zadowolenie klienta i jest to najważniejszy test. Unit testy są dobre bo pomagają zrozumieć programiście co tak na prawdę chce osiągnąć w modelu. Jednak testowanie dla samego testowania (i 90+% pokrycia) nie jest niezbędne. Co więcej może być przeszkodą w bardziej dynamicznym rozwoju oprogramowania.

Stosuję zasadę: cucumber first w każdym projekcie z zaawansowanymi programistami. Dzięki temu mamy należycie przetestowaną funkcjonalność jakiej spodziewa się klient. W początkowych fazach projektu wcale nie testujemy modeli - bo są zbyt trywialne. Na ogół wystarczy sprawdzenie czy przykładowa fabryka prawidłowo tworzy obiekt.

Dopiero później, gdy modele robią się bardziej skomplikowane i zawierają coraz więcej logiki zaczynamy je testować. Wtedy projekt jest już najczęściej tak rozbudowany, że przygotowanie testu cucumbera dla każdego use case byłoby zbyt praco- i czasochłonne. Wtedy też dopiero podejmujemy decyzję: przenieść test do unit testu.

Tutaj uwaga dla ludzi, którzy z testami dopiero zaczynają. Cucumber jest fajny jeżeli ktoś to czyta poza programistami. W innym przypadku polecam rozważenie używania test/unit lub rspec z capybarą. Bardzo często wśród początkujących zachodzi mylne przeświadczenie, że testy integracyjne to tylko i wyłącznie cucumber. Tak, cucumber został stworzony z myślą o testach integracyjnych i przy użyciu z railsami generuje zestaw kroków dla capybary, ale nie znaczy to wcale, że nie ma żadnej alternatywy.

Mnie szczerze mówiąc męczy trochę używanie cucumbera. Szczególnie jeżeli celem jest mocny zestaw testów funkcjonalnych. Wtedy zaczynają się pojawiać edge case’y i elementy, które dużo łatwiej byłoby przetestować stosując testy w rspecu/test unit. Dodatkowo bolączką wielu test suitów są bardzo rozbudowane sekcjeg “Given”. Jeżeli trzeba przygotować dużo danych, to testy aż roją się od wielkich tabelek.

Wracając do czytelności, w większości wypadków testy integracyjne w rspec’u lub test unit będą tak samo czytelne jak cucumber, np:

[code]Factory.create(:post)

visit homepage_path

within("#posts") do
page.should have_content(“Something”)
end[/code]

[quote]Stosuję zasadę: cucumber first w każdym projekcie z zaawansowanymi programistami. Dzięki temu mamy należycie przetestowaną funkcjonalność jakiej spodziewa się klient. W początkowych fazach projektu wcale nie testujemy modeli - bo są zbyt trywialne. Na ogół wystarczy sprawdzenie czy przykładowa fabryka prawidłowo tworzy obiekt.

Dopiero później, gdy modele robią się bardziej skomplikowane i zawierają coraz więcej logiki zaczynamy je testować. Wtedy projekt jest już najczęściej tak rozbudowany, że przygotowanie testu cucumbera dla każdego use case byłoby zbyt praco- i czasochłonne. Wtedy też dopiero podejmujemy decyzję: przenieść test do unit testu.[/quote]
Jak określasz to “dopiero później”? :wink:

Moim zdaniem w modelu powinna być przetestowana każda publiczna metoda, niezależnie od tego jak jest trywialna. Przy czym raczej nie lubię testowania jednolinijkowców typu validates_presence_of :name, to się zupełnie mija z celem.

Na omijanie testów jednostkowych trzeba też uważać z bardzo prostego powodu, testy funkcjonalne sprzyjają rozrzucaniu się kodu po kontrolerach i widokach. W testach funkcjonalnych nie ma różnicy czy w kontrolerze jest jedna czy 100 linijek kodu. Podczas pisania testów jednostkowych jest już inaczej, bo żeby łatwo przygotować test, warto mieć jakieś fajne API.

Według mnie czasami jest sens np. gdy ktoś zmienia error_message, gdy jest jakieś odstępstwo od domyślnego zachowania.

Czasami rzeczywiście warto, ale niech to będą wyjątki, a nie reguła :wink: (chociaż różne są podejścia, niektórzy twierdzą, że używając mark to też jest jedna linijka w testach, więc czemu tego nie sprawdzić?)

You forgot Steak!


:wink:

Oraz: tak, jeśli testy akceptacyjne nie mają być czytane, zmieniane bądź układane przez nietechnicznego, to wtedy taki np. Steak (czyli zasadniczo RSpec + Capybara + trochę helperów) pisze się przyjemniej i bardziej [dla programisty] naturalnie niż ogóry.
(oraz: lepsza integracja z istniejącym test suite, Cucumber jest trochę “z innej planety”)

[quote=piotrj]Witam,

Zastanawiam się czy natrafiliście na jakiś projekt opensource w railsach, który polecilibyście jako wzór do naśladowania.[/quote]