diff options
Diffstat (limited to 'guides/source')
| -rw-r--r-- | guides/source/4_0_release_notes.md | 3 | ||||
| -rw-r--r-- | guides/source/action_mailer_basics.md | 22 | ||||
| -rw-r--r-- | guides/source/asset_pipeline.md | 26 | ||||
| -rw-r--r-- | guides/source/command_line.md | 4 | ||||
| -rw-r--r-- | guides/source/configuring.md | 42 | ||||
| -rw-r--r-- | guides/source/contributing_to_ruby_on_rails.md | 1 | ||||
| -rw-r--r-- | guides/source/documents.yaml | 5 | ||||
| -rw-r--r-- | guides/source/getting_started.md | 50 | ||||
| -rw-r--r-- | guides/source/i18n.md | 2 | ||||
| -rw-r--r-- | guides/source/layouts_and_rendering.md | 93 | ||||
| -rw-r--r-- | guides/source/performance_testing.md | 676 | ||||
| -rw-r--r-- | guides/source/testing.md | 6 |
12 files changed, 102 insertions, 828 deletions
diff --git a/guides/source/4_0_release_notes.md b/guides/source/4_0_release_notes.md index 655f26e253..a678dd9d90 100644 --- a/guides/source/4_0_release_notes.md +++ b/guides/source/4_0_release_notes.md @@ -67,6 +67,7 @@ In Rails 4.0, several features have been extracted into gems. You can simply add * Action Caching ([Github](https://github.com/rails/actionpack-action_caching), [Pull Request](https://github.com/rails/rails/pull/7833)) * Page Caching ([Github](https://github.com/rails/actionpack-page_caching), [Pull Request](https://github.com/rails/rails/pull/7833)) * Sprockets ([Github](https://github.com/rails/sprockets-rails)) +* Performance tests ([Github](https://github.com/rails/rails-perftest), [Pull Request](https://github.com/rails/rails/pull/8876)) Documentation ------------- @@ -84,7 +85,7 @@ Please refer to the [Changelog](https://github.com/rails/rails/blob/master/railt * New test locations `test/models`, `test/helpers`, `test/controllers`, and `test/mailers`. Corresponding rake tasks added as well. ([Pull Request](https://github.com/rails/rails/pull/7878)) -* Your app's executables now live in the `bin/` dir. Run `rake update:bin` to get `bin/bundle`, `bin/rails`, and `bin/rake`. +* Your app's executables now live in the `bin/` dir. Run `rake rails:update:bin` to get `bin/bundle`, `bin/rails`, and `bin/rake`. * Threadsafe on by default diff --git a/guides/source/action_mailer_basics.md b/guides/source/action_mailer_basics.md index 7c6ef52f4a..513ae1272f 100644 --- a/guides/source/action_mailer_basics.md +++ b/guides/source/action_mailer_basics.md @@ -575,3 +575,25 @@ end ``` In the test we send the email and store the returned object in the `email` variable. We then ensure that it was sent (the first assert), then, in the second batch of assertions, we ensure that the email does indeed contain what we expect. + +NOTE: The `ActionMailer::Base.deliveries` array is only reset automatically in `ActionMailer::TestCase` tests. If you want to have a clean slate outside Action Mailer tests, you can reset it manually with: `ActionMailer::Base.deliveries.clear` + +Intercepting Emails +------------------- +There are situations where you need to edit an email before it's delivered. Fortunately Action Mailer provides hooks to intercept every email. You can register an interceptor to make modifications to mail messages right before they are handed to the delivery agents. + +```ruby +class SandboxEmailInterceptor + def self.delivering_email(message) + message.to = ['sandbox@example.com'] + end +end +``` + +Before the interceptor can do its job you need to register it with the Action Mailer framework. You can do this in an initializer file `config/initializers/sandbox_email_interceptor.rb` + +```ruby +ActionMailer::Base.register_interceptor(SandboxEmailInterceptor) if Rails.env.staging? +``` + +NOTE: The example above uses a custom environment called "staging" for a production like server but for testing purposes. You can read [Creating Rails environments](./configuring.html#creating-rails-environments) for more information about custom Rails environments. diff --git a/guides/source/asset_pipeline.md b/guides/source/asset_pipeline.md index 34bf3ba210..e939606c88 100644 --- a/guides/source/asset_pipeline.md +++ b/guides/source/asset_pipeline.md @@ -720,7 +720,31 @@ A good example of this is the `jquery-rails` gem which comes with Rails as the s Making Your Library or Gem a Pre-Processor ------------------------------------------ -TODO: Registering gems on [Tilt](https://github.com/rtomayko/tilt) enabling Sprockets to find them. +As Sprockets uses [Tilt](https://github.com/rtomayko/tilt) as a generic +interface to different templating engines, your gem should just +implement the Tilt template protocol. Normally, you would subclass +`Tilt::Template` and reimplement `evaluate` method to return final +output. Template source is stored at `@code`. Have a look at +[`Tilt::Template`](https://github.com/rtomayko/tilt/blob/master/lib/tilt/template.rb) +sources to learn more. + +```ruby +module BangBang + class Template < ::Tilt::Template + # Adds a "!" to original template. + def evaluate(scope, locals, &block) + "#{@code}!" + end + end +end +``` + +Now that you have a `Template` class, it's time to associate it with an +extenstion for template files: + +```ruby +Sprockets.register_engine '.bang', BangBang::Template +``` Upgrading from Old Versions of Rails ------------------------------------ diff --git a/guides/source/command_line.md b/guides/source/command_line.md index 12d39ea1cc..2790a4740a 100644 --- a/guides/source/command_line.md +++ b/guides/source/command_line.md @@ -355,7 +355,7 @@ rake assets:clean # Remove compiled assets rake assets:precompile # Compile all the assets named in config.assets.precompile rake db:create # Create the database from config/database.yml for the current Rails.env ... -rake log:clear # Truncates all *.log files in log/ to zero bytes +rake log:clear # Truncates all *.log files in log/ to zero bytes (specify which logs with LOGS=test,development) rake middleware # Prints out your Rack middleware stack ... rake tmp:clear # Clear session, cache, and socket files from tmp/ (narrow w/ tmp:sessions:clear, tmp:cache:clear, tmp:sockets:clear) @@ -442,7 +442,7 @@ app/model/post.rb: NOTE. When using specific annotations and custom annotations, the annotation name (FIXME, BUG etc) is not displayed in the output lines. -By default, `rake notes` will look in the `app`, `config`, `lib`, `script` and `test` directories. If you would like to search other directories, you can provide them as a comma separated list in an environment variable `SOURCE_ANNOTATION_DIRECTORIES`. +By default, `rake notes` will look in the `app`, `config`, `lib`, `bin` and `test` directories. If you would like to search other directories, you can provide them as a comma separated list in an environment variable `SOURCE_ANNOTATION_DIRECTORIES`. ```bash $ export SOURCE_ANNOTATION_DIRECTORIES='rspec,vendor' diff --git a/guides/source/configuring.md b/guides/source/configuring.md index 676458f046..c1f31fd2b0 100644 --- a/guides/source/configuring.md +++ b/guides/source/configuring.md @@ -177,7 +177,6 @@ The full set of methods that can be used in this block are as follows: * `javascripts` turns on the hook for JavaScript files in generators. Used in Rails for when the `scaffold` generator is run. Defaults to `true`. * `javascript_engine` configures the engine to be used (for eg. coffee) when generating assets. Defaults to `nil`. * `orm` defines which orm to use. Defaults to `false` and will use Active Record by default. -* `performance_tool` defines which performance tool to use. Defaults to `nil`. * `resource_controller` defines which generator to use for generating a controller when using `rails generate resource`. Defaults to `:controller`. * `scaffold_controller` different from `resource_controller`, defines which generator to use for generating a _scaffolded_ controller when using `rails generate scaffold`. Defaults to `:scaffold_controller`. * `stylesheets` turns on the hook for stylesheets in generators. Used in Rails for when the `scaffold` generator is run, but this hook can be used in other generates as well. Defaults to `true`. @@ -346,34 +345,6 @@ The schema dumper adds one additional configuration option: * `config.action_view.erb_trim_mode` gives the trim mode to be used by ERB. It defaults to `'-'`. See the [ERB documentation](http://www.ruby-doc.org/stdlib/libdoc/erb/rdoc/) for more information. -* `config.action_view.javascript_expansions` is a hash containing expansions that can be used for the JavaScript include tag. By default, this is defined as: - - ```ruby - config.action_view.javascript_expansions = { :defaults => %w(jquery jquery_ujs) } - ``` - - However, you may add to this by defining others: - - ```ruby - config.action_view.javascript_expansions[:prototype] = [ - 'prototype', 'effects', 'dragdrop', 'controls' - ] - ``` - - And can reference in the view with the following code: - - ```ruby - <%= javascript_include_tag :prototype %> - ``` - -* `config.action_view.stylesheet_expansions` works in much the same way as `javascript_expansions`, but has no default key. Keys defined for this hash can be referenced in the view like such: - - ```ruby - <%= stylesheet_link_tag :special %> - ``` - -* `config.action_view.cache_asset_ids` With the cache enabled, the asset tag helper methods will make fewer expensive file system calls (the default implementation checks the file system timestamp). However this prevents you from modifying any asset files while the server is running. - * `config.action_view.embed_authenticity_token_in_remote_forms` allows you to set the default behavior for `authenticity_token` in forms with `:remote => true`. By default it's set to false, which means that remote forms will not include `authenticity_token`, which is helpful when you're fragment-caching the form. Remote forms get the authenticity from the `meta` tag, so embedding is unnecessary unless you support browsers without JavaScript. In such case you can either pass `:authenticity_token => true` as a form option or set this config setting to `true` * `config.action_view.prefix_partial_path_with_controller_namespace` determines whether or not partials are looked up from a subdirectory in templates rendered from namespaced controllers. For example, consider a controller named `Admin::PostsController` which renders this template: @@ -553,6 +524,15 @@ development: Change the username and password in the `development` section as appropriate. +### Creating Rails Environments + +By default Rails ships with three environments: "development", "test", and "production". While these are sufficient for most use cases, there are circumstances when you want more environments. + +Imagine you have a server which mirrors the production environment but is only used for testing. Such a server is commonly called a "staging server". To define an environment called "staging" for this server just by create a file called `config/environments/staging.rb`. Please use the contents of any existing file in `config/environments` as a starting point and make the necessary changes from there. + +That environment is no different than the default ones, start a server with `rails server -e staging`, a console with `rails console staging`, `Rails.env.staging?` works, etc. + + Rails Environment Settings -------------------------- @@ -673,10 +653,6 @@ Below is a comprehensive list of all the initializers found in Rails in the orde * `action_dispatch.configure` Configures the `ActionDispatch::Http::URL.tld_length` to be set to the value of `config.action_dispatch.tld_length`. -* `action_view.cache_asset_ids` Sets `ActionView::Helpers::AssetTagHelper::AssetPaths.cache_asset_ids` to `false` when Active Support loads, but only if `config.cache_classes` is too. - -* `action_view.javascript_expansions` Registers the expansions set up by `config.action_view.javascript_expansions` and `config.action_view.stylesheet_expansions` to be recognized by Action View and therefore usable in the views. - * `action_view.set_configs` Sets up Action View by using the settings in `config.action_view` by `send`'ing the method names as setters to `ActionView::Base` and passing the values through. * `action_controller.logger` Sets `ActionController::Base.logger` — if it's not already set — to `Rails.logger`. diff --git a/guides/source/contributing_to_ruby_on_rails.md b/guides/source/contributing_to_ruby_on_rails.md index 7c5a472971..baef620c6c 100644 --- a/guides/source/contributing_to_ruby_on_rails.md +++ b/guides/source/contributing_to_ruby_on_rails.md @@ -216,6 +216,7 @@ Rails follows a simple set of coding style conventions: * Use `MyClass.my_method(my_arg)` not `my_method( my_arg )` or `my_method my_arg`. * Use `a = b` and not `a=b`. * Use assert_not methods instead of refute. +* Prefer `method { do_stuff }` instead of `method{do_stuff}` for single-line blocks. * Follow the conventions in the source you see used already. The above are guidelines — please use your best judgment in using them. diff --git a/guides/source/documents.yaml b/guides/source/documents.yaml index e779407fab..c73bbeb90d 100644 --- a/guides/source/documents.yaml +++ b/guides/source/documents.yaml @@ -84,10 +84,6 @@ url: debugging_rails_applications.html description: This guide describes how to debug Rails applications. It covers the different ways of achieving this and how to understand what is happening "behind the scenes" of your code. - - name: Performance Testing Rails Applications - url: performance_testing.html - description: This guide covers the various ways of performance testing a Ruby on Rails application. - - name: Configuring Rails Applications url: configuring.html description: This guide covers the basic configuration settings for a Rails application. @@ -106,7 +102,6 @@ description: This guide documents the asset pipeline. - name: Working with JavaScript in Rails - work_in_progress: true url: working_with_javascript_in_rails.html description: This guide covers the built-in Ajax/JavaScript functionality of Rails. - diff --git a/guides/source/getting_started.md b/guides/source/getting_started.md index 7d86b3866a..c394f30c38 100644 --- a/guides/source/getting_started.md +++ b/guides/source/getting_started.md @@ -583,9 +583,31 @@ content: </p> ``` -Finally, if you now go to -<http://localhost:3000/posts/new> you'll -be able to create a post. Try it! +If you now go to +<http://localhost:3000/posts/new> you'll *almost* be able to create a post. Try +it! You should get an error that looks like this: + + + +Rails has several security features that help you write secure applications, +and you're running into one of them now. This one is called +'strong_parameters,' which requires us to tell Rails exactly which parameters +we want to accept in our controllers. In this case, we want to allow the +'title' and 'text' parameters, so change your `create` controller action to +look like this: + +``` + def create + @post = Post.new(params[:post].permit(:title, :text)) + + @post.save + redirect_to action: :show, id: @post.id + end +``` + +See the `permit`? It allows us to accept both `title` and `text` in this +action. With this change, you should finally be able to create new `Post`s. +Visit <http://localhost:3000/posts/new> and give it a try!  @@ -711,10 +733,11 @@ class Post < ActiveRecord::Base end ``` -These changes will ensure that all posts have a title that is at least five characters long. -Rails can validate a variety of conditions in a model, including the presence or uniqueness of columns, their -format, and the existence of associated objects. Validations are covered in detail -in [Active Record Validations and Callbacks](active_record_validations_callbacks.html#validations-overview) +These changes will ensure that all posts have a title that is at least five +characters long. Rails can validate a variety of conditions in a model, +including the presence or uniqueness of columns, their format, and the +existence of associated objects. Validations are covered in detail in [Active +Record Validations](active_record_validations.html) With the validation now in place, when you call `@post.save` on an invalid post, it will return `false`. If you open `app/controllers/posts_controller.rb` @@ -729,7 +752,7 @@ def new end def create - @post = Post.new(params[:post]) + @post = Post.new(params[:post].permit(:title, :text)) if @post.save redirect_to action: :show, id: @post.id @@ -864,8 +887,8 @@ method: :patch do |f| %> This time we point the form to the `update` action, which is not defined yet but will be very soon. -The `method: :patch` option tells Rails that we want this form to be -submitted via the `PUT` HTTP method which is the HTTP method you're expected to use to +The `method: :patch` option tells Rails that we want this form to be submitted +via the `PATCH` HTTP method which is the HTTP method you're expected to use to **update** resources according to the REST protocol. TIP: By default forms built with the _form_for_ helper are sent via `POST`. @@ -883,7 +906,7 @@ And then create the `update` action in `app/controllers/posts_controller.rb`: def update @post = Post.find(params[:id]) - if @post.update(params[:post]) + if @post.update(params[:post].permit(:title, :text)) redirect_to action: :show, id: @post.id else render 'edit' @@ -1388,7 +1411,7 @@ Let's wire up the `create` in `app/controllers/comments_controller.rb`: class CommentsController < ApplicationController def create @post = Post.find(params[:post_id]) - @comment = @post.comments.create(params[:comment]) + @comment = @post.comments.create(params[:comment].permit(:commenter, :body)) redirect_to post_path(@post) end end @@ -1559,6 +1582,9 @@ Then you make the `app/views/posts/show.html.erb` look like the following: <%= @post.text %> </p> +<h2>Comments</h2> +<%= render @post.comments %> + <h2>Add a comment:</h2> <%= render "comments/form" %> diff --git a/guides/source/i18n.md b/guides/source/i18n.md index 69232d9bd4..5304ca4285 100644 --- a/guides/source/i18n.md +++ b/guides/source/i18n.md @@ -102,7 +102,7 @@ The **translations load path** (`I18n.load_path`) is just a Ruby Array of paths NOTE: The backend will lazy-load these translations when a translation is looked up for the first time. This makes it possible to just swap the backend with something else even after translations have already been announced. -The default initializer `locale.rb` file has instructions on how to add locales from another directory and how to set a different default locale. Just uncomment and edit the specific lines. +The default `application.rb` files has instructions on how to add locales from another directory and how to set a different default locale. Just uncomment and edit the specific lines. ```ruby # The default locale is :en and all translations from config/locales/*.rb,yml are auto loaded. diff --git a/guides/source/layouts_and_rendering.md b/guides/source/layouts_and_rendering.md index 7c26512046..339008ab9e 100644 --- a/guides/source/layouts_and_rendering.md +++ b/guides/source/layouts_and_rendering.md @@ -695,72 +695,6 @@ To include `http://example.com/main.js`: <%= javascript_include_tag "http://example.com/main.js" %> ``` -If the application does not use the asset pipeline, the `:defaults` option loads jQuery by default: - -```erb -<%= javascript_include_tag :defaults %> -``` - -Outputting `script` tags such as this: - -```html -<script src="/javascripts/jquery.js"></script> -<script src="/javascripts/jquery_ujs.js"></script> -``` - -These two files for jQuery, `jquery.js` and `jquery_ujs.js` must be placed inside `public/javascripts` if the application doesn't use the asset pipeline. These files can be downloaded from the [jquery-rails repository on GitHub](https://github.com/indirect/jquery-rails/tree/master/vendor/assets/javascripts) - -WARNING: If you are using the asset pipeline, this tag will render a `script` tag for an asset called `defaults.js`, which would not exist in your application unless you've explicitly created it. - -And you can in any case override the `:defaults` expansion in `config/application.rb`: - -```ruby -config.action_view.javascript_expansions[:defaults] = %w(foo.js bar.js) -``` - -You can also define new defaults: - -```ruby -config.action_view.javascript_expansions[:projects] = %w(projects.js tickets.js) -``` - -And use them by referencing them exactly like `:defaults`: - -```erb -<%= javascript_include_tag :projects %> -``` - -When using `:defaults`, if an `application.js` file exists in `public/javascripts` it will be included as well at the end. - -Also, if the asset pipeline is disabled, the `:all` expansion loads every JavaScript file in `public/javascripts`: - -```erb -<%= javascript_include_tag :all %> -``` - -Note that your defaults of choice will be included first, so they will be available to all subsequently included files. - -You can supply the `:recursive` option to load files in subfolders of `public/javascripts` as well: - -```erb -<%= javascript_include_tag :all, recursive: true %> -``` - -If you're loading multiple JavaScript files, you can create a better user experience by combining multiple files into a single download. To make this happen in production, specify `cache: true` in your `javascript_include_tag`: - -```erb -<%= javascript_include_tag "main", "columns", cache: true %> -``` - -By default, the combined file will be delivered as `javascripts/all.js`. You can specify a location for the cached asset file instead: - -```erb -<%= javascript_include_tag "main", "columns", - cache: "cache/main/display" %> -``` - -You can even use dynamic paths such as `cache/#{current_site}/main/display`. - #### Linking to CSS Files with the `stylesheet_link_tag` The `stylesheet_link_tag` helper returns an HTML `<link>` tag for each source provided. @@ -797,33 +731,6 @@ By default, the `stylesheet_link_tag` creates links with `media="screen" rel="st <%= stylesheet_link_tag "main_print", media: "print" %> ``` -If the asset pipeline is disabled, the `all` option links every CSS file in `public/stylesheets`: - -```erb -<%= stylesheet_link_tag :all %> -``` - -You can supply the `:recursive` option to link files in subfolders of `public/stylesheets` as well: - -```erb -<%= stylesheet_link_tag :all, recursive: true %> -``` - -If you're loading multiple CSS files, you can create a better user experience by combining multiple files into a single download. To make this happen in production, specify `cache: true` in your `stylesheet_link_tag`: - -```erb -<%= stylesheet_link_tag "main", "columns", cache: true %> -``` - -By default, the combined file will be delivered as `stylesheets/all.css`. You can specify a location for the cached asset file instead: - -```erb -<%= stylesheet_link_tag "main", "columns", - cache: "cache/main/display" %> -``` - -You can even use dynamic paths such as `cache/#{current_site}/main/display`. - #### Linking to Images with the `image_tag` The `image_tag` helper builds an HTML `<img />` tag to the specified file. By default, files are loaded from `public/images`. diff --git a/guides/source/performance_testing.md b/guides/source/performance_testing.md deleted file mode 100644 index 6bc175d3b6..0000000000 --- a/guides/source/performance_testing.md +++ /dev/null @@ -1,676 +0,0 @@ -Performance Testing Rails Applications -====================================== - -This guide covers the various ways of performance testing a Ruby on Rails -application. - -After reading this guide, you will know: - -* The various types of benchmarking and profiling metrics. -* How to generate performance and benchmarking tests. -* How to install and use a GC-patched Ruby binary to measure memory usage and object - allocation. -* The benchmarking information provided by Rails inside the log files. -* Various tools facilitating benchmarking and profiling. - -Performance testing is an integral part of the development cycle. It is very -important that you don't make your end users wait for too long before the page -is completely loaded. Ensuring a pleasant browsing experience for end users and -cutting the cost of unnecessary hardware is important for any non-trivial web -application. - --------------------------------------------------------------------------------- - -Performance Test Cases ----------------------- - -Rails performance tests are a special type of integration tests, designed for -benchmarking and profiling the test code. With performance tests, you can -determine where your application's memory or speed problems are coming from, -and get a more in-depth picture of those problems. - -In a freshly generated Rails application, `test/performance/browsing_test.rb` -contains an example of a performance test: - -```ruby -require 'test_helper' -require 'rails/performance_test_help' - -class BrowsingTest < ActionDispatch::PerformanceTest - # Refer to the documentation for all available options - # self.profile_options = { runs: 5, metrics: [:wall_time, :memory], - # output: 'tmp/performance', formats: [:flat] } - - test "homepage" do - get '/' - end -end -``` - -This example is a simple performance test case for profiling a GET request to -the application's homepage. - -### Generating Performance Tests - -Rails provides a generator called `performance_test` for creating new -performance tests: - -```bash -$ rails generate performance_test homepage -``` - -This generates `homepage_test.rb` in the `test/performance` directory: - -```ruby -require 'test_helper' -require 'rails/performance_test_help' - -class HomepageTest < ActionDispatch::PerformanceTest - # Refer to the documentation for all available options - # self.profile_options = { runs: 5, metrics: [:wall_time, :memory], - # output: 'tmp/performance', formats: [:flat] } - - test "homepage" do - get '/' - end -end -``` - -### Examples - -Let's assume your application has the following controller and model: - -```ruby -# routes.rb -root to: 'home#dashboard' -resources :posts - -# home_controller.rb -class HomeController < ApplicationController - def dashboard - @users = User.last_ten.includes(:avatars) - @posts = Post.all_today - end -end - -# posts_controller.rb -class PostsController < ApplicationController - def create - @post = Post.create(params[:post]) - redirect_to(@post) - end -end - -# post.rb -class Post < ActiveRecord::Base - before_save :recalculate_costly_stats - - def slow_method - # I fire gallzilion queries sleeping all around - end - - private - - def recalculate_costly_stats - # CPU heavy calculations - end -end -``` - -#### Controller Example - -Because performance tests are a special kind of integration test, you can use -the `get` and `post` methods in them. - -Here's the performance test for `HomeController#dashboard` and -`PostsController#create`: - -```ruby -require 'test_helper' -require 'rails/performance_test_help' - -class PostPerformanceTest < ActionDispatch::PerformanceTest - def setup - # Application requires logged-in user - login_as(:lifo) - end - - test "homepage" do - get '/dashboard' - end - - test "creating new post" do - post '/posts', post: { body: 'lifo is fooling you' } - end -end -``` - -You can find more details about the `get` and `post` methods in the -[Testing Rails Applications](testing.html) guide. - -#### Model Example - -Even though the performance tests are integration tests and hence closer to -the request/response cycle by nature, you can still performance test pure model -code. - -Performance test for `Post` model: - -```ruby -require 'test_helper' -require 'rails/performance_test_help' - -class PostModelTest < ActionDispatch::PerformanceTest - test "creation" do - Post.create body: 'still fooling you', cost: '100' - end - - test "slow method" do - # Using posts(:awesome) fixture - posts(:awesome).slow_method - end -end -``` - -### Modes - -Performance tests can be run in two modes: Benchmarking and Profiling. - -#### Benchmarking - -Benchmarking makes it easy to quickly gather a few metrics about each test run. -By default, each test case is run **4 times** in benchmarking mode. - -To run performance tests in benchmarking mode: - -```bash -$ rake test:benchmark -``` - -#### Profiling - -Profiling allows you to make an in-depth analysis of each of your tests by using -an external profiler. Depending on your Ruby interpreter, this profiler can be -native (Rubinius, JRuby) or not (MRI, which uses RubyProf). By default, each -test case is run **once** in profiling mode. - -To run performance tests in profiling mode: - -```bash -$ rake test:profile -``` - -### Metrics - -Benchmarking and profiling run performance tests and give you multiple metrics. -The availability of each metric is determined by the interpreter being used—none -of them support all metrics—and by the mode in use. A brief description of each -metric and their availability across interpreters/modes is given below. - -#### Wall Time - -Wall time measures the real world time elapsed during the test run. It is -affected by any other processes concurrently running on the system. - -#### Process Time - -Process time measures the time taken by the process. It is unaffected by any -other processes running concurrently on the same system. Hence, process time -is likely to be constant for any given performance test, irrespective of the -machine load. - -#### CPU Time - -Similar to process time, but leverages the more accurate CPU clock counter -available on the Pentium and PowerPC platforms. - -#### User Time - -User time measures the amount of time the CPU spent in user-mode, i.e. within -the process. This is not affected by other processes and by the time it possibly -spends blocked. - -#### Memory - -Memory measures the amount of memory used for the performance test case. - -#### Objects - -Objects measures the number of objects allocated for the performance test case. - -#### GC Runs - -GC Runs measures the number of times GC was invoked for the performance test case. - -#### GC Time - -GC Time measures the amount of time spent in GC for the performance test case. - -#### Metric Availability - -##### Benchmarking - -| Interpreter | Wall Time | Process Time | CPU Time | User Time | Memory | Objects | GC Runs | GC Time | -| ------------ | --------- | ------------ | -------- | --------- | ------ | ------- | ------- | ------- | -| **MRI** | yes | yes | yes | no | yes | yes | yes | yes | -| **REE** | yes | yes | yes | no | yes | yes | yes | yes | -| **Rubinius** | yes | no | no | no | yes | yes | yes | yes | -| **JRuby** | yes | no | no | yes | yes | yes | yes | yes | - -##### Profiling - -| Interpreter | Wall Time | Process Time | CPU Time | User Time | Memory | Objects | GC Runs | GC Time | -| ------------ | --------- | ------------ | -------- | --------- | ------ | ------- | ------- | ------- | -| **MRI** | yes | yes | no | no | yes | yes | yes | yes | -| **REE** | yes | yes | no | no | yes | yes | yes | yes | -| **Rubinius** | yes | no | no | no | no | no | no | no | -| **JRuby** | yes | no | no | no | no | no | no | no | - -NOTE: To profile under JRuby you'll need to run `export JRUBY_OPTS="-Xlaunch.inproc=false --profile.api"` -**before** the performance tests. - -### Understanding the Output - -Performance tests generate different outputs inside `tmp/performance` directory -depending on their mode and metric. - -#### Benchmarking - -In benchmarking mode, performance tests generate two types of outputs. - -##### Command Line - -This is the primary form of output in benchmarking mode. Example: - -```bash -BrowsingTest#test_homepage (31 ms warmup) - wall_time: 6 ms - memory: 437.27 KB - objects: 5,514 - gc_runs: 0 - gc_time: 19 ms -``` - -##### CSV Files - -Performance test results are also appended to `.csv` files inside `tmp/performance`. -For example, running the default `BrowsingTest#test_homepage` will generate -following five files: - -* BrowsingTest#test_homepage_gc_runs.csv -* BrowsingTest#test_homepage_gc_time.csv -* BrowsingTest#test_homepage_memory.csv -* BrowsingTest#test_homepage_objects.csv -* BrowsingTest#test_homepage_wall_time.csv - -As the results are appended to these files each time the performance tests are -run in benchmarking mode, you can collect data over a period of time. This can -be very helpful in analyzing the effects of code changes. - -Sample output of `BrowsingTest#test_homepage_wall_time.csv`: - -```bash -measurement,created_at,app,rails,ruby,platform -0.00738224999999992,2009-01-08T03:40:29Z,,3.0.0,ruby-1.8.7.249,x86_64-linux -0.00755874999999984,2009-01-08T03:46:18Z,,3.0.0,ruby-1.8.7.249,x86_64-linux -0.00762099999999993,2009-01-08T03:49:25Z,,3.0.0,ruby-1.8.7.249,x86_64-linux -0.00603075000000008,2009-01-08T04:03:29Z,,3.0.0,ruby-1.8.7.249,x86_64-linux -0.00619899999999995,2009-01-08T04:03:53Z,,3.0.0,ruby-1.8.7.249,x86_64-linux -0.00755449999999991,2009-01-08T04:04:55Z,,3.0.0,ruby-1.8.7.249,x86_64-linux -0.00595999999999997,2009-01-08T04:05:06Z,,3.0.0,ruby-1.8.7.249,x86_64-linux -0.00740450000000004,2009-01-09T03:54:47Z,,3.0.0,ruby-1.8.7.249,x86_64-linux -0.00603150000000008,2009-01-09T03:54:57Z,,3.0.0,ruby-1.8.7.249,x86_64-linux -0.00771250000000012,2009-01-09T15:46:03Z,,3.0.0,ruby-1.8.7.249,x86_64-linux -``` - -#### Profiling - -In profiling mode, performance tests can generate multiple types of outputs. -The command line output is always presented but support for the others is -dependent on the interpreter in use. A brief description of each type and -their availability across interpreters is given below. - -##### Command Line - -This is a very basic form of output in profiling mode: - -```bash -BrowsingTest#test_homepage (58 ms warmup) - process_time: 63 ms - memory: 832.13 KB - objects: 7,882 -``` - -##### Flat - -Flat output shows the metric—time, memory, etc—measure in each method. -[Check Ruby-Prof documentation for a better explanation](http://ruby-prof.rubyforge.org/files/examples/flat_txt.html). - -##### Graph - -Graph output shows the metric measure in each method, which methods call it and -which methods it calls. [Check Ruby-Prof documentation for a better explanation](http://ruby-prof.rubyforge.org/files/examples/graph_txt.html). - -##### Tree - -Tree output is profiling information in calltree format for use by [kcachegrind](http://kcachegrind.sourceforge.net/html/Home.html) -and similar tools. - -##### Output Availability - -| | Flat | Graph | Tree | -| ------------ | ---- | ----- | ---- | -| **MRI** | yes | yes | yes | -| **REE** | yes | yes | yes | -| **Rubinius** | yes | yes | no | -| **JRuby** | yes | yes | no | - -### Tuning Test Runs - -Test runs can be tuned by setting the `profile_options` class variable on your -test class. - -```ruby -require 'test_helper' -require 'rails/performance_test_help' - -class BrowsingTest < ActionDispatch::PerformanceTest - self.profile_options = { runs: 5, metrics: [:wall_time, :memory] } - - test "homepage" - get '/' - end -end -``` - -In this example, the test would run 5 times and measure wall time and memory. -There are a few configurable options: - -| Option | Description | Default | Mode | -| ---------- | ------------------------------------------ | ----------------------------- | --------- | -| `:runs` | Number of runs. | Benchmarking: 4, Profiling: 1 | Both | -| `:output` | Directory to use when writing the results. | `tmp/performance` | Both | -| `:metrics` | Metrics to use. | See below. | Both | -| `:formats` | Formats to output to. | See below. | Profiling | - -Metrics and formats have different defaults depending on the interpreter in use. - -| Interpreter | Mode | Default metrics | Default formats | -| -------------- | ------------ | ------------------------------------------------------- | ----------------------------------------------- | -| **MRI/REE** | Benchmarking | `[:wall_time, :memory, :objects, :gc_runs, :gc_time]` | N/A | -| | Profiling | `[:process_time, :memory, :objects]` | `[:flat, :graph_html, :call_tree, :call_stack]` | -| **Rubinius** | Benchmarking | `[:wall_time, :memory, :objects, :gc_runs, :gc_time]` | N/A | -| | Profiling | `[:wall_time]` | `[:flat, :graph]` | -| **JRuby** | Benchmarking | `[:wall_time, :user_time, :memory, :gc_runs, :gc_time]` | N/A | -| | Profiling | `[:wall_time]` | `[:flat, :graph]` | - -As you've probably noticed by now, metrics and formats are specified using a -symbol array with each name [underscored.](http://api.rubyonrails.org/classes/String.html#method-i-underscore) - -### Performance Test Environment - -Performance tests are run in the `test` environment. But running performance -tests will set the following configuration parameters: - -```bash -ActionController::Base.perform_caching = true -ActiveSupport::Dependencies.mechanism = :require -Rails.logger.level = ActiveSupport::Logger::INFO -``` - -As `ActionController::Base.perform_caching` is set to `true`, performance tests -will behave much as they do in the `production` environment. - -### Installing GC-Patched MRI - -To get the best from Rails' performance tests under MRI, you'll need to build -a special Ruby binary with some super powers. - -The recommended patches for MRI can be found on [RVM's _patches_ directory](https://github.com/wayneeseguin/rvm/tree/master/patches/ruby) -under each specific interpreter version. - -Concerning the installation itself, you can either do this easily by using -[RVM](https://rvm.io/) or you can build everything from source, -which is a little bit harder. - -#### Install Using RVM - -The process of installing a patched Ruby interpreter is very easy if you let RVM -do the hard work. All of the following RVM commands will provide you with a -patched Ruby interpreter: - -```bash -$ rvm install 1.9.2-p180 --patch gcdata -$ rvm install 1.9.2-p180 --patch ~/Downloads/downloaded_gcdata_patch.patch -``` - -You can even keep your regular interpreter by assigning a name to the patched -one: - -```bash -$ rvm install 1.9.2-p180 --patch gcdata --name gcdata -$ rvm use 1.9.2-p180 # your regular ruby -$ rvm use 1.9.2-p180-gcdata # your patched ruby -``` - -And it's done! You have installed a patched Ruby interpreter. - -#### Install From Source - -This process is a bit more complicated, but straightforward nonetheless. If -you've never compiled a Ruby binary before, follow these steps to build a -Ruby binary inside your home directory. - -##### Download and Extract - -```bash -$ mkdir rubygc -$ wget <the version you want from ftp://ftp.ruby-lang.org/pub/ruby> -$ tar -xzvf <ruby-version.tar.gz> -$ cd <ruby-version> -``` - -##### Apply the Patch - -```bash -$ curl https://raw.github.com/wayneeseguin/rvm/master/patches/ruby/1.9.2/p180/gcdata.patch | patch -p0 # if you're on 1.9.2! -``` - -##### Configure and Install - -The following will install Ruby in your home directory's `/rubygc` directory. -Make sure to replace `<homedir>` with a full patch to your actual home -directory. - -```bash -$ ./configure --prefix=/<homedir>/rubygc -$ make && make install -``` - -##### Prepare Aliases - -For convenience, add the following lines in your `~/.profile`: - -```bash -alias gcruby='~/rubygc/bin/ruby' -alias gcrake='~/rubygc/bin/rake' -alias gcgem='~/rubygc/bin/gem' -alias gcirb='~/rubygc/bin/irb' -alias gcrails='~/rubygc/bin/rails' -``` - -Don't forget to use your aliases from now on. - -### Using Ruby-Prof on MRI and REE - -Add Ruby-Prof to your applications' Gemfile if you want to benchmark/profile -under MRI or REE: - -```ruby -gem 'ruby-prof' -``` - -Now run `bundle install` and you're ready to go. - -Command Line Tools ------------------- - -Writing performance test cases could be an overkill when you are looking for one -time tests. Rails ships with two command line tools that enable quick and dirty -performance testing: - -### `benchmarker` - -Usage: - -```bash -Usage: rails benchmarker 'Ruby.code' 'Ruby.more_code' ... [OPTS] - -r, --runs N Number of runs. - Default: 4 - -o, --output PATH Directory to use when writing the results. - Default: tmp/performance - -m, --metrics a,b,c Metrics to use. - Default: wall_time,memory,objects,gc_runs,gc_time -``` - -Example: - -```bash -$ rails benchmarker 'Item.all' 'CouchItem.all' --runs 3 --metrics wall_time,memory -``` - -### `profiler` - -Usage: - -```bash -Usage: rails profiler 'Ruby.code' 'Ruby.more_code' ... [OPTS] - -r, --runs N Number of runs. - Default: 1 - -o, --output PATH Directory to use when writing the results. - Default: tmp/performance - -m, --metrics a,b,c Metrics to use. - Default: process_time,memory,objects - -f, --formats x,y,z Formats to output to. - Default: flat,graph_html,call_tree -``` - -Example: - -```bash -$ rails profiler 'Item.all' 'CouchItem.all' --runs 2 --metrics process_time --formats flat -``` - -NOTE: Metrics and formats vary from interpreter to interpreter. Pass `--help` to -each tool to see the defaults for your interpreter. - -Helper Methods --------------- - -Rails provides various helper methods inside Active Record, Action Controller -and Action View to measure the time taken by a given piece of code. The method -is called `benchmark()` in all the three components. - -### Model - -```ruby -Project.benchmark("Creating project") do - project = Project.create("name" => "stuff") - project.create_manager("name" => "David") - project.milestones << Milestone.all -end -``` - -This benchmarks the code enclosed in the `Project.benchmark("Creating project") do...end` -block and prints the result to the log file: - -```ruby -Creating project (185.3ms) -``` - -Please refer to the [API docs](http://api.rubyonrails.org/classes/ActiveSupport/Benchmarkable.html#method-i-benchmark) -for additional options to `benchmark()`. - -### Controller - -Similarly, you could use this helper method inside [controllers.](http://api.rubyonrails.org/classes/ActiveSupport/Benchmarkable.html) - -```ruby -def process_projects - benchmark("Processing projects") do - Project.process(params[:project_ids]) - Project.update_cached_projects - end -end -``` - -NOTE: `benchmark` is a class method inside controllers. - -### View - -And in [views](http://api.rubyonrails.org/classes/ActiveSupport/Benchmarkable.html:) - -```erb -<% benchmark("Showing projects partial") do %> - <%= render @projects %> -<% end %> -``` - -Request Logging ---------------- - -Rails log files contain very useful information about the time taken to serve -each request. Here's a typical log file entry: - -```bash -Processing ItemsController#index (for 127.0.0.1 at 2009-01-08 03:06:39) [GET] -Rendering template within layouts/items -Rendering items/index -Completed in 5ms (View: 2, DB: 0) | 200 OK [http://0.0.0.0/items] -``` - -For this section, we're only interested in the last line: - -```bash -Completed in 5ms (View: 2, DB: 0) | 200 OK [http://0.0.0.0/items] -``` - -This data is fairly straightforward to understand. Rails uses millisecond(ms) as -the metric to measure the time taken. The complete request spent 5 ms inside -Rails, out of which 2 ms were spent rendering views and none was spent -communication with the database. It's safe to assume that the remaining 3 ms -were spent inside the controller. - -Michael Koziarski has an [interesting blog post](http://www.therailsway.com/2009/1/6/requests-per-second) -explaining the importance of using milliseconds as the metric. - -Useful Links ------------- - -### Rails Plugins and Gems - -* [Rails Analyzer](http://rails-analyzer.rubyforge.org) -* [Rails Footnotes](https://github.com/josevalim/rails-footnotes/tree/master) -* [Query Reviewer](https://github.com/nesquena/query_reviewer) -* [MiniProfiler](http://www.miniprofiler.com) - -### Generic Tools - -* [httperf](http://www.hpl.hp.com/research/linux/httperf/) -* [ab](http://httpd.apache.org/docs/2.2/programs/ab.html) -* [JMeter](http://jakarta.apache.org/jmeter/) -* [kcachegrind](http://kcachegrind.sourceforge.net/html/Home.html) - -### Tutorials and Documentation - -* [ruby-prof API Documentation](http://ruby-prof.rubyforge.org) -* [Request Profiling Railscast](http://railscasts.com/episodes/98-request-profiling) - Outdated, but useful for understanding call graphs. - -Commercial Products -------------------- - -Rails has been lucky to have a few companies dedicated to Rails-specific -performance tools. A couple of those are: - -* [New Relic](http://www.newrelic.com) -* [Scout](http://scoutapp.com) diff --git a/guides/source/testing.md b/guides/source/testing.md index 0b3bed8dbe..39a44794a7 100644 --- a/guides/source/testing.md +++ b/guides/source/testing.md @@ -39,10 +39,10 @@ Rails creates a `test` folder for you as soon as you create a Rails project usin ```bash $ ls -F test -fixtures/ functional/ integration/ performance/ test_helper.rb unit/ +fixtures/ functional/ integration/ test_helper.rb unit/ ``` -The `unit` directory is meant to hold tests for your models, the `functional` directory is meant to hold tests for your controllers, the `integration` directory is meant to hold tests that involve any number of controllers interacting, and the `performance` directory is meant for performance tests. +The `unit` directory is meant to hold tests for your models, the `functional` directory is meant to hold tests for your controllers and the `integration` directory is meant to hold tests that involve any number of controllers interacting. Fixtures are a way of organizing test data; they reside in the `fixtures` folder. @@ -760,14 +760,12 @@ You don't need to set up and run your tests by hand on a test-by-test basis. Rai | Tasks | Description | | ------------------------------- | ----------- | | `rake test` | Runs all unit, functional and integration tests. You can also simply run `rake` as the _test_ target is the default.| -| `rake test:benchmark` | Benchmark the performance tests| | `rake test:controllers` | Runs all the controller tests from `test/controllers`| | `rake test:functionals` | Runs all the functional tests from `test/controllers`, `test/mailers`, and `test/functional`| | `rake test:helpers` | Runs all the helper tests from `test/helpers`| | `rake test:integration` | Runs all the integration tests from `test/integration`| | `rake test:mailers` | Runs all the mailer tests from `test/mailers`| | `rake test:models` | Runs all the model tests from `test/models`| -| `rake test:profile` | Profile the performance tests| | `rake test:recent` | Tests recent changes| | `rake test:uncommitted` | Runs all the tests which are uncommitted. Supports Subversion and Git| | `rake test:units` | Runs all the unit tests from `test/models`, `test/helpers`, and `test/unit`| |