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”? 
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.