Ten tutorial zakłada, że przyswoiłeś już sobie podstawy Railsów zapoznając się z przewodnikiem Zaczynamy z Ruby on Rails.
1 Podstawy linii poleceń
Znajomość kilku podstawowych komend to absolutna konieczność. Będziesz z nich często korzystać w codziennej pracy. Te najważniejsze to odpowiednio:
- rails console
- rails server
- rake
- rails generate
- rails dbconsole
- rails new app_name
Stworzymy teraz prostą aplikację, abyś mógł się z nimi zaznajomić w praktyce.
1.1 rails new
Pierwszym krokiem będzie stworzenie nowej aplikacji poprzez polecenie rails, po uprzednim zainstalowaniu Railsów.
Oczywiście, zdajesz sobie sprawę, że aby to zrobić musisz mieć już zainstalowane Railsy, prawda? Najlepiej zrobić to za pomocą gema, poleceniem gem install rails.
$ rails new commandsapp
create
create README
create .gitignore
create Rakefile
create config.ru
create Gemfile
create app
...
create log/production.log
create log/development.log
create log/test.log
Wywołanie tej jednej maleńkiej komendy wygenerowało dla ciebie całkiem spore ilości kodu. Masz już gotową strukturę katalogów oraz kod potrzebny do działania naszej prostej aplikacji.
Efekt działania tej komendy może ci się teraz wydać nieco przytłaczający. Spokojnie, kiedy omówimy polecenie generate wszystko stanie się jasne.
1.2 server
Pora sprawdzić jak to działa! Komenda server uruchomi serwer WWW o nazwie WEBrick, który standardowo dołączony jest do Rubiego. Będziemy z niego korzystać za każdym razem, gdy będziemy chcieli zobaczyć w przeglądarce efekty naszej pracy.
Możesz też zastosować alternatywne serwery. Ich omówieniem zajmiemy się w innej części przewodnika.
Wywołanie komendy server natychmiast uruchomi serwer, który obsłuży naszą wspaniałą nową aplikacje:
$ cd commandsapp
$ ./script/server
=> Booting WEBrick...
=> Rails 2.2.0 application started on http://0.0.0.0:3000
=> Ctrl-C to shutdown server; call with --help for options
[2008-11-04 10:11:38] INFO WEBrick 1.3.1
[2008-11-04 10:11:38] INFO ruby 1.8.5 (2006-12-04) [i486-linux]
[2008-11-04 10:11:38] INFO WEBrick::HTTPServer#start: pid=18994 port=3000
I proszę, przy pomocy zaledwie trzech komend postawiliśmy serwer Railsowy na porcie 3000. A teraz nie zwlekaj! Nie zwlekaj, czym prędzej otwórz przeglądarkę i uruchom http://localhost:3000.
I jak? Nienajgorzej, co? Wszystko działa. nasza aplikacja nie jest może na razie zbyt funkcjonalna, ale zaraz się tym zajmiemy.
1.3 generate
Komenda generate używa szablonów (templates) do tworzenia wielu różnych rzeczy. Możesz sprawdzić co jest dostępne wywołując komendę generate bez dodatkowych opcji. Spróbujmy:
$ ./script/generate
Usage: ./script/generate generator [options] [args]
...
...
Installed Generators
Built-in: controller, integration_test, mailer, migration, model, observer, performance_test, plugin, resource, scaffold, session_migration
...
...
Możesz zainstalować dodatkowe generatory poprzez odpowiednie gemy, wtyczki (plugins) lub tworząc je samemu.
Stosując generatory zaoszczędzisz mnóstwo czasu, który spędziłbyś na pisanie niezbędnych, ale wtórnych fragmentów kodów (tzw. boilerplate code).
Stwórzmy teraz własny kontroler stosując generator kontrolerów. Ale jakiej komendy powinniśmy użyć. Zapytajmy generatora:
Wszystkie polecenia konsoli Railsów mają dołączoną pomoc. Podobnie jak przy większości poleceń systemów uniksowch i uniksopodobnych, możesz spróbować ją wywołać dodając opcję --help lub -h na końcu komendy, np.: ./script/server --help.
$ ./script/generate controller
Usage: ./script/generate controller ControllerName [options]
...
...
Example:
./script/generate controller CreditCard open debit credit close
Credit card controller with URLs like /credit_card/debit.
Controller: app/controllers/credit_card_controller.rb
Views: app/views/credit_card/debit.html.erb [...]
Helper: app/helpers/credit_card_helper.rb
Test: test/functional/credit_card_controller_test.rb
Modules Example:
./script/generate controller 'admin/credit_card' suspend late_fee
Credit card admin controller with URLs /admin/credit_card/suspend.
Controller: app/controllers/admin/credit_card_controller.rb
Views: app/views/admin/credit_card/debit.html.erb [...]
Helper: app/helpers/admin/credit_card_helper.rb
Test: test/functional/admin/credit_card_controller_test.rb
Jak widzimy, generator kontrolerów żąda dodatkowych parametrów w postaci generate controller NazwaKontrolera akcja1 akcja2. Stworzymy więc kontroler powitania o nazwie Greetings i akcji hello, który grzecznie się z nami przywita.
$ ./script/generate controller Greetings hello
exists app/controllers/
exists app/helpers/
create app/views/greetings
exists test/functional/
create app/controllers/greetings_controller.rb
create test/functional/greetings_controller_test.rb
create app/helpers/greetings_helper.rb
create app/views/greetings/hello.html.erb
Spójrzmy co się stało. Co zostało wygenerowane? Generator upewnił się, że pewne katalogi już istnieją w naszej aplikacji, a następnie stworzył plik kontrolera, plik testowy, helper dla widoku oraz plik widoku.
Zajrzyjmy do kodu kontrolera i nieco go zmodyfikujmy (app/controllers/greetings_controller.rb):
class GreetingsController < ApplicationController
def hello
@message = "Hello, how are you today? I am exuberant!"
end
end
A teraz otwórzmy widok, który wyświetli nasze urocze powitanie (app/views/greetings/hello.html.erb):
<h1>A Greeting for You!</h1>
<p><%= @message %></p>
Gotowe. Sprawdź teraz jak to wygląda w przeglądarce. Pamiętaj o uruchomieniu serwera. Możesz to zrobić za pomocą ./script/server wywołanego z głównego katalogu twojej aplikacji.
$ ./script/server
=> Booting WEBrick...
Upewnij się, że w katalogu app/views/(controller) nie znajdują się żadne kopie zapasowe plików z tyldą, w przeciwnym wypadku WEBrick nie wyświetli poprawnych rezultatów. To zdaje się bug Railsów w wersji 2.3.0.
Adres to http://localhost:3000/greetings/hello.
Adres URL standardowej aplikacji Railsowej, opiera się na schemacie http://(host)/(kontroler)/(akcja), a adres http://(host)/(kontroler) wywołuje akcję index kontrolera.
“Ale co z danymi?”, mógłbyś zapytać. Otóż Railsy oferują także generator modeli danych. Jak myślisz ja go wywołać?
$ ./script/generate model
Usage: ./script/generate model ModelName [field:type, field:type]
...
Examples:
./script/generate model account
creates an Account model, test, fixture, and migration:
Model: app/models/account.rb
Test: test/unit/account_test.rb
Fixtures: test/fixtures/accounts.yml
Migration: db/migrate/XXX_add_accounts.rb
./script/generate model post title:string body:text published:boolean
creates a Post model with a string title, text body, and published flag.
Ale zamiast generować model bezpośrednio (czym zajmiemy się później) postawimy teraz rusztowanie (scaffold). Rusztowanie to w Rails model, migracja bazy danych dla tego modelu, kontroler do jego obsługi, widoki do wyświetlania i manipulowania danymi, i zestaw testowy dla każdego z powyższych.
Stworzymy teraz prosty zasób, który nazwiemy “HighScore”. Będzie on zawierał nasze najwyższe wyniki osiągnięte w grach, w jakie ostatnio graliśmy.
$ ./script/generate scaffold HighScore game:string score:integer
exists app/models/
exists app/controllers/
exists app/helpers/
create app/views/high_scores
create app/views/layouts/
exists test/functional/
create test/unit/
create public/stylesheets/
create app/views/high_scores/index.html.erb
create app/views/high_scores/show.html.erb
create app/views/high_scores/new.html.erb
create app/views/high_scores/edit.html.erb
create app/views/layouts/high_scores.html.erb
create public/stylesheets/scaffold.css
create app/controllers/high_scores_controller.rb
create test/functional/high_scores_controller_test.rb
create app/helpers/high_scores_helper.rb
route map.resources :high_scores
dependency model
exists app/models/
exists test/unit/
create test/fixtures/
create app/models/high_score.rb
create test/unit/high_score_test.rb
create test/fixtures/high_scores.yml
exists db/migrate
create db/migrate/20081217071914_create_high_scores.rb
Po kolei. Generator sprawdza czy istnieją katalogi dla modeli, kontrolerów, helperów, layoutów, testów funkcjonalnych i jednostkowych, arkuszy stylów (stylesheet). Następnie tworzy widoki, kontrolery, modele i migracje baz danych dla zasobu HighScore (tworzy tabelę high_scores i pola). W końcu zajmuje się drogą routingu zasobu i nowymi testami dla wszystkich elementów.
Migracja wymaga wykonania pewnego kodu (zawartego w pliku 20081217071914_create_high_scores.rb) w celu modyfikacji bazy danych. Ale właściwie jakiej bazy? Bazy danych sqlite3, którą Railsy za chwilę dla ciebie utworzą, gdy wywołamy polecenie rake db:migrate. Szczegółowym omówieniem tej komendy zajmiemy się nieco później.
Hej, skoro już mowa o sqlite3, pora zainstalować jego gem poleceniem gem install sqlite3-ruby.
$ rake db:migrate
(in /home/commandsapp)
CreateHighScores: migrating
create_table(:high_scores)
-> 0.0070s
CreateHighScores: migrated (0.0077s)
Pomówmy teraz o testach jednostkowych. Testy jednostkowe to kod odpowiedzialny za testowanie i przedstawianie uwag na temat testowanego kodu. W procesie testowym, brany jest niewielki fragment kodu, powiedzmy metoda modelu, a następnie sprawdzane są dane wejściowe i wyjściowe tej metody. Zapamiętaj testy jednostkowe to twoi kumple. Im wcześniej zdasz sobie sprawę, że mogą znacząco ułatwić ci życie tym lepiej. Serio! Zaraz jakiś przeprowadzimy.
Spójrzmy na interfejs jaki przygotowały dla nas Railsy. ./script/server; http://localhost:3000/high_scores
Możemy teraz dodać jakiś rekordowy wynik (55,160 dla Space Invaders!)
1.4 console
Komenda console pozwala ci komunikować się ze swoją aplikacją za pomocą linii poleceń. script/console korzysta z IRB, więc jeśli korzystałeś już z tej powłoki praca z konsolą będzie dla ciebie intuicyjna. Konsola przydaje się głównie do szybkiego sprawdzania świeżych pomysłów, bez interferowania w kod strony.
1.5 dbconsole
dbconsole sprawdza, której bazy danych używasz i natychmiastowo uruchamia dla ciebie interfejs linii poleceń jakiego z nią używasz (dodatkowo sprawdza i podpowiada ci parametry). Działa poprawnie z MySQl, PostgreSQL, SQLite i SQLite3.
1.6 plugin
Komenda plugin ułatwia zarządzanie wtyczkami, można by ją określić mianem miniaturowego RubyGems. Jak zainstalować wtyczkę? Możesz wywołać podkomendę discover, która przejrzy repozytoria w poszukiwaniu wtyczek lub wywołać source, aby dodać konkretne repozytorium wtyczek lub bezpośrednio określić ścieżkę do wtyczki.
Powiedzmy, że chcesz stworzyć witrynę dla klienta, który potrzebuje niewielkiego systemu księgowości. Wszystko co wiąże się z obrotem pieniędzmi powinno być odnotowane i niemożliwe do usunięcia. Czy nie byłoby to wspaniałe, gdybyśmy mogli odejść od domyślnego zachowania modelu, tak by nie można było usunąć jego rekordu, a zamiast tego aktualizowane było jakieś pole?
Istnieje taka możliwość! Wtyczka, o której mowa to “acts_as_paranoid”. Pozwala ona modelowi na dodanie kolumny “deleted_at”, którego pole modyfikowane będzie przy wywołaniu polecenia destroy. Później, przy wywołaniu find, wtyczka dołączy sprawdzenie bazy w celu odfiltrowania “usuniętych” rzeczy.
$ ./script/plugin install http://svn.techno-weenie.net/projects/plugins/acts_as_paranoid
+ ./CHANGELOG
+ ./MIT-LICENSE
...
...
1.7 runner
runner wykonuje kod Rubiego w kontekście Railsów, bez interakcji. Na przykład:
$ ./script/runner "Model.long_running_method"
1.8 destroy
Możesz myśleć o poleceniu destroy jako przeciwieństwie generate. Sprawdzi ono jakie były efekty wywołania generate i odwróci wprowadzone zmiany. Uwierz mi, że przy pisaniu tego tutoriala, komenda ta przydawała się wielokrotnie.
$ ./script/generate model Oops
exists app/models/
exists test/unit/
exists test/fixtures/
create app/models/oops.rb
create test/unit/oops_test.rb
create test/fixtures/oops.yml
exists db/migrate
create db/migrate/20081221040817_create_oops.rb
$ ./script/destroy model Oops
notempty db/migrate
notempty db
rm db/migrate/20081221040817_create_oops.rb
rm test/fixtures/oops.yml
rm test/unit/oops_test.rb
rm app/models/oops.rb
notempty test/fixtures
notempty test
notempty test/unit
notempty test
notempty app/models
notempty app
1.9 about
Wyświetla: numer wersji Rubiego, RubyGems, Railsów i ich komponentów, katalog główny twojej aplikacji, nazwę bieżącego środowiska Railsowego, rodzaj bazy danych twojej aplikacji oraz wersję jej schematu. Ta komenda bardzo się przydaje, gdy chcesz kogoś prosić o pomoc, sprawdzić czy łatka zabezpieczeń nie zaszkodzi lub gdy potrzebujesz statystyk dla istniejącej instalacji Railsów.
$ ./script/about
About your application's environment
Ruby version 1.8.6 (i486-linux)
RubyGems version 1.3.1
Rails version 2.2.0
Active Record version 2.2.0
Action Pack version 2.2.0
Active Resource version 2.2.0
Action Mailer version 2.2.0
Active Support version 2.2.0
Edge Rails revision unknown
Application root /home/commandsapp
Environment development
Database adapter sqlite3
Database schema version 20081217073400
2 Zaawansowane narzędzia linii poleceń
Bardziej zaawansowane sposoby korzystania z linii poleceń polegają na dopasowywaniu narzędzi do swoich potrzeb, poprzez ciągłe eksperymenty i odkrywanie przydatnych, a niejednokrotnie zaskakujących opcji. W tej sekcji postaramy się omówić kilka użytecznych trików.
2.1 Railsy, a bazy danych i systemy zarządzania kodem źródłowym (SCM)
Tworząc nową aplikację Railsową, mamy od razu możliwość zadeklarowania rodzaju bazy danych i systemu zarządzanie kodem źródłowym (source code management system) jakich będziemy używać w naszej aplikacji. Dzięki temu z pewnością zaoszczędzimy trochę czasu.
Zobaczmy jaki będzie efekt zastosowania opcji --git i --database=postgresql:
$ mkdir gitapp
$ cd gitapp
$ git init
Initialized empty Git repository in .git/
$ rails new . --git --database=postgresql
exists
create app/controllers
create app/helpers
...
...
create tmp/cache
create tmp/pids
create Rakefile
add 'Rakefile'
create README
add 'README'
create app/controllers/application_controller_.rb
add 'app/controllers/application_controller_.rb'
create app/helpers/application_helper.rb
...
create log/test.log
add 'log/test.log'
Musieliśmy dodać katalog gitapp oraz zainicjalizować puste repozytorium git, zanim Railsy dodałyby pliki stworzone dla naszego repozytorium. Zobaczmy w jaki sposób została zmodyfikowana konfiguracja bazy:
$ cat config/database.yml
# PostgreSQL. Versions 7.4 and 8.x are supported.
#
# Install the ruby-postgres driver:
# gem install ruby-postgres
# On Mac OS X:
# gem install ruby-postgres -- --include=/usr/local/pgsql
# On Windows:
# gem install ruby-postgres
# Choose the win32 build.
# Install PostgreSQL and put its /bin directory on your path.
development:
adapter: postgresql
encoding: unicode
database: gitapp_development
pool: 5
username: gitapp
password:
...
...
Dzięki tym opcjom także plik database.yml został wzbogacony o kilka linijek kodu, oczywiście zgodnie z naszym wyborem – w tym przypadku bazą PostgreSQL. Jedyną niedogodnością związaną z opcją SCM jest konieczność stworzenia odpowiedniego katalogu przed inicjalizacją SCM. Później można już skorzystać z komendy rails, aby wygenerować podstawy dla aplikacji
2.2 server i różne serwery WWW
Dostępnych jest wiele różnych serwerów WWW Rubiego, większość z nich powinna współpracować z Railsami. Railsy w wersji 2.3. posługują się już interfejsem webowym Rack do obsługi stron internetowych. Oznacza to, że dla naszej aplikacji możemy wybrać dowolny Serwer WWW obsługujący zapytania Rack w tym min. WEBrick, Mongrel, Thin, Phusion Passenger i inne.
Aby dowiedzieć więcej na temat Rack, zajrzyj do przewodnika Rails on Rack.
Aby użyć innego serwera zainstaluj po prostu jego gem, a następnie użyj jego nazwy jako pierwszego parametru skryptu script/server:
$ sudo gem install mongrel
Building native extensions. This could take a while...
Building native extensions. This could take a while...
Successfully installed gem_plugin-0.2.3
Successfully installed fastthread-1.0.1
Successfully installed cgi_multipart_eof_fix-2.5.0
Successfully installed mongrel-1.1.5
...
...
Installing RDoc documentation for mongrel-1.1.5...
$ script/server mongrel
=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails 2.2.0 application starting on http://0.0.0.0:3000
...
2.3 Generatory w Railsach
Na stronie Understanding Generators znajdziesz bardzo szegółowy opis działania generatorów. Znaczna jego część znalazła się w tym przewodniku.
Generatory to kod służący generowaniu kodu. Najlepiej zobaczmy to w praktyce. Nasz generator wygeneruje plik tekstowy.
Oto katalogi, w których generator railsów będzie domyślnie poszukiwał dostępnych generatorów, przy założeniu, że Rails.root to główny katalog twojej aplikacji (np. /home/foobar/commandsapp):
- Rails.root/lib/generators
- Rails.root/vendor/generators
- Wewnątrz jakiejkolwiek wtyczki z katalogiem jak “generators”, czy “rails_generators”
- ~/.rails/generators
- Wewnątrz jakiegokolwiek Gema, który został zainstalowany pod nazwą kończącą się ciągiem “_generator”
- Wewnątrz jakiegokolwiek Gema, który został zainstalowany ze ścieżką “rails_generators” i “_generator.rb” w nazwie pliku
- Wreszcie pośród wbudowanych generatorów (kontrolerów, modeli, itp.)
Posłużymy się teraz czwartą możliwością (w katalogu domowym). Jej efektów najłatwiej się pozbyć.
$ mkdir -p ~/.rails/generators/tutorial_test/templates
$ touch ~/.rails/generators/tutorial_test/templates/tutorial.erb
$ touch ~/.rails/generators/tutorial_test/tutorial_test_generator.rb
Umieszczamy następujący kod w pliku tutorial_test_generator.rb:
class TutorialTestGenerator < Rails::Generator::Base
def initialize(*runtime_args)
super(*runtime_args)
@tut_args = runtime_args
end
def manifest
record do |m|
m.directory "public"
m.template "tutorial.erb", File.join("public", "tutorial.txt"),
:assigns => { :args => @tut_args }
end
end
end
Bierzemy dowolne dostarczone argumenty, zapisujemy je w zmiennej instancyjnej i bez żadnej modyfikacji kopiujemy, implementujemy metodę manifest, która wywołuje record, który:
- Sprawdza czy katalog public istnieje.
- Korzysta z szablonu ERb o nazwie “tutorial.erb”.
- Zapisujemy w “Rails.root/public/tutorial.txt”.
- Przekazuje argumnty zapisane za pomocą parametru :assign.
Teraz przygotujemy szablon:
$ cat ~/.rails/generators/tutorial_test/templates/tutorial.erb
Jestem szablonem!
Przypisano mi pewne argumenty:
<%= require 'pp'; PP.pp(args, "") %>
Upewnimy się jeszcze że nasz generator znalazł się na liście dostępnych generatorów:
$ ./script/generate
...
...
Installed Generators
User: tutorial_test
Znakomicie. Teraz wygenerujemy jakiś tekst!
$ ./script/generate tutorial_test arg1 arg2 arg3
exists public
create public/tutorial.txt
Rezultat:
$ cat public/tutorial.txt
Jestem szablonem!
Przypisano mi pewne argumenty:
[["arg1", "arg2", "arg3"],
{:collision=>:ask,
:quiet=>false,
:generator=>"tutorial_test",
:command=>:create}]
Tada!
2.4 Rake to Make Rubiego
Rake jest samodzielnym narzędziem, będącym odpowiednikiem uniksowego ‘make’, który za pomocą ‘Rakefile’ i plików .rake tworzy listę zadań. Rake służy do zadań ogólno administracyjnych, szczególnie tych bardzo złożonych, które się ze sobą wzajemnie łączą.
Aby uzyskać listę dostępnych zadań, które na ogół zależne będą od katalogu, w którym się znajdujesz, posłuż się poleceniem rake --tasks. Każde z zadań ma opis, w którym znajdziesz wszystko co istotne.
rake --tasks
(in /home/developer/commandsapp)
rake db:abort_if_pending_migrations # Raises an error if there are pending migrations
rake db:charset # Retrieves the charset for the current environment's database
rake db:collation # Retrieves the collation for the current environment's database
rake db:create # Create the database defined in config/database.yml for the current RAILS_ENV
...
...
rake tmp:pids:clear # Clears all files in tmp/pids
rake tmp:sessions:clear # Clears all files in tmp/sessions
rake tmp:sockets:clear # Clears all files in tmp/sockets
Przyjrzyjmy się kilku z tych około 80 zadań.
2.4.1 db: Bazy danych
Najbardziej podstawowe zadania Rake db: to migrate i create. Warto wypróbować wszystkie zadania migracji (up, down, redo, reset). Zadaniem przydatnym przy rozwiązywaniu problemów jest rake db:version, który wyświetla bieżącą wersję bazy danych.
2.4.2 doc: Dokumentacja
Jeśli chcesz się pozbyć lub przebudować, któreś z elementów dokumentacji Railsów, możesz posłużyć się zadaniami doc. “Odchudzenie” dokumentacji okażę się przydatne np. przy tworzeniu aplikacji na platformy osadzone (embedded platforms).
2.4.3 gems: Ruby gems
Możesz określić, z których gemów będzie korzystać twoja aplikacja, a rake gems:install zainstaluje je dla ciebie. Zaglądnij do pliku environment.rb, aby dowiedzieć się jak to zrobić przy pomocy dyrektywy config.gem.
gems:unpack rozpakuje gem, czyli skopiuje kod Gema do katalogu vendor/gems. W ten sposób zwiększysz objętość aplikacji, ale i znacząco uprościsz jej instalacje na nowych hostach, eliminując konieczność uruchamiania rake gems:install, czy wyszukiwania i instalacji gemów potrzebnych dla działania twojej aplikacji.
2.4.4 notes: Wyliczenie linii kodu z dołączoną notatką
Te zadania przeszukają twój kod w poszukiwaniu linii rozpoczynających się od notatki “FIXME”, “OPTIMIZE”, “TODO”, czy dowolnej przyjętej (jak XXX) i wylistuje je dla ciebie.
2.4.5 rails: Zadania frameworka Rails
Oprócz wspomnianego już zadania umożliwiającego rozpakowanie dodatkowych gemów, Rake daje ci także możliwość rozpakowania gemów samego frameworka. Znajdą się one w vendor/rails. Wywołując rake rails:freeze:gems rozpakujesz wersję, której aktualnie używasz, natomiast rake rails:freeze:edge rozpakuje najnowszą wersję Railsów (wersja edge).
Kiedy zamrozisz (freeze) gemy, Railsy będą używały w pierwszej kolejności kodu z katalogu vendor/rails zamiast gemów systemu. Możesz “odmrozić” Railsy poleceniem rake rails:unfreeze.
Po aktualizacji Railsów dobrze jest uruchomić rails:update, który zaktualizuje katalogi konfiguracji oraz skryptów. Zaktualizuje także dedykowane Railsowe javascript (takie jak np. Scriptaculous).
2.4.6 test: Testy Railsowe
Solidny opis testów jednostkowych znajdziesz w podręczniku Testowanie aplikacji railsowej
Railsy dostarczają zestawu testów zwanego Test::Unit. To właśnie dużej ilości testów Railsy zawdzięczają swoją stabilność.
Zadania test: pomagają w przeprowadzaniu różnego rodzaju testów, które, mamy nadzieję, napiszesz.
2.4.7 time: Strefy czasowe
Możesz wylistować wszystkie strefy czasowe znane Railom, za pomocą polecenia rake time:zones:all. Jest to zadanie bardzo przydatne w codziennej pracy.
2.4.8 tmp: Pliki tymczasowe
Katalog tymczasowy, podobnie jak w systemach uniksowych jest miejscem, gdzie przechowywane są pliki tymczasowe, jak np. pliki sesji, czy przechowywane w pamięci cache akcje. Zadania tmp: pomogą ci pozbyć się zbędnych plików tymczasowych lub pomogą je stworzyć.