diff options
Diffstat (limited to 'guides/source')
-rw-r--r-- | guides/source/active_record_querying.md | 4 | ||||
-rw-r--r-- | guides/source/asset_pipeline.md | 2 | ||||
-rw-r--r-- | guides/source/getting_started.md | 7 | ||||
-rw-r--r-- | guides/source/testing.md | 25 |
4 files changed, 19 insertions, 19 deletions
diff --git a/guides/source/active_record_querying.md b/guides/source/active_record_querying.md index aea7515974..3676462788 100644 --- a/guides/source/active_record_querying.md +++ b/guides/source/active_record_querying.md @@ -559,8 +559,8 @@ SELECT * FROM clients WHERE (clients.locked != 1) ### OR Conditions -`OR` condition between two relations can be build by calling `or` on the first relation -and passing the second one as an argument. +`OR` conditions between two relations can be built by calling `or` on the first +relation, and passing the second one as an argument. ```ruby Client.where(locked: true).or(Client.where(orders_count: [1,3,5])) diff --git a/guides/source/asset_pipeline.md b/guides/source/asset_pipeline.md index 61b7112247..22b6b278d7 100644 --- a/guides/source/asset_pipeline.md +++ b/guides/source/asset_pipeline.md @@ -868,7 +868,7 @@ pre-existing JavaScript runtimes, you may want to add one to your Gemfile: ```ruby group :production do - gem 'therubyracer' + gem 'mini_racer' end ``` diff --git a/guides/source/getting_started.md b/guides/source/getting_started.md index 5553f08456..49c691c841 100644 --- a/guides/source/getting_started.md +++ b/guides/source/getting_started.md @@ -208,7 +208,7 @@ TIP: Compiling CoffeeScript and JavaScript asset compression requires you have a JavaScript runtime available on your system, in the absence of a runtime you will see an `execjs` error during asset compilation. Usually macOS and Windows come with a JavaScript runtime installed. -Rails adds the `therubyracer` gem to the generated `Gemfile` in a +Rails adds the `mini_racer` gem to the generated `Gemfile` in a commented line for new apps and you can uncomment if you need it. `therubyrhino` is the recommended runtime for JRuby users and is added by default to the `Gemfile` in apps generated under JRuby. You can investigate @@ -910,6 +910,7 @@ And then finally, add the view for this action, located at <tr> <th>Title</th> <th>Text</th> + <th></th> </tr> <% @articles.each do |article| %> @@ -1489,14 +1490,14 @@ second argument, and then the options as another argument. The `method: :delete` and `data: { confirm: 'Are you sure?' }` options are used as HTML5 attributes so that when the link is clicked, Rails will first show a confirm dialog to the user, and then submit the link with method `delete`. This is done via the -JavaScript file `jquery_ujs` which is automatically included in your +JavaScript file `rails-ujs` which is automatically included in your application's layout (`app/views/layouts/application.html.erb`) when you generated the application. Without this file, the confirmation dialog box won't appear.  -TIP: Learn more about jQuery Unobtrusive Adapter (jQuery UJS) on +TIP: Learn more about Unobtrusive JavaScript on [Working With JavaScript in Rails](working_with_javascript_in_rails.html) guide. Congratulations, you can now create, show, list, update and destroy diff --git a/guides/source/testing.md b/guides/source/testing.md index 1db48ed56c..565f40ed37 100644 --- a/guides/source/testing.md +++ b/guides/source/testing.md @@ -350,7 +350,7 @@ Rails adds some custom assertions of its own to the `minitest` framework: | --------------------------------------------------------------------------------- | ------- | | [`assert_difference(expressions, difference = 1, message = nil) {...}`](http://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#method-i-assert_difference) | Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block.| | [`assert_no_difference(expressions, message = nil, &block)`](http://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#method-i-assert_no_difference) | Asserts that the numeric result of evaluating an expression is not changed before and after invoking the passed in block.| -| [`assert_changes(expressions, message = nil, from:, to:, &block) {...}`](http://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#method-i-assert_changes) | Test that the result of evaluating an expression is changed after invoking the passed in block.| +| [`assert_changes(expressions, message = nil, from:, to:, &block)`](http://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#method-i-assert_changes) | Test that the result of evaluating an expression is changed after invoking the passed in block.| | [`assert_no_changes(expressions, message = nil, &block)`](http://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#method-i-assert_no_changes) | Test the result of evaluating an expression is not changed after invoking the passed in block.| | [`assert_nothing_raised { block }`](http://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#method-i-assert_nothing_raised) | Ensures that the given block doesn't raise any exceptions.| | [`assert_recognizes(expected_options, path, extras={}, message=nil)`](http://api.rubyonrails.org/classes/ActionDispatch/Assertions/RoutingAssertions.html#method-i-assert_recognizes) | Asserts that the routing of the given path was handled correctly and that the parsed options (given in the expected_options hash) match path. Basically, it asserts that Rails recognizes the route given by expected_options.| @@ -602,11 +602,8 @@ Model tests don't have their own superclass like `ActionMailer::TestCase` instea System Testing -------------- -System tests are full-browser tests that can be used to test your application's -JavaScript and user experience. System tests use Capybara as a base. - -System tests allow for running tests in either a real browser or a headless -driver for testing full user interactions with your application. +System tests allows test user interactions with your application, running tests +in either a real or a headless browser. System tests uses Capybara as base. For creating Rails system tests, you use the `test/system` directory in your application. Rails provides a generator to create a system test skeleton for you. @@ -660,8 +657,9 @@ end The driver name is a required argument for `driven_by`. The optional arguments that can be passed to `driven_by` are `:using` for the browser (this will only -be used by Selenium), and `:screen_size` to change the size of the screen for -screenshots. +be used by Selenium), `:screen_size` to change the size of the screen for +screenshots, and `:options` which can be used to set options supported by the +driver. ```ruby require "test_helper" @@ -671,8 +669,9 @@ class ApplicationSystemTestCase < ActionDispatch::SystemTestCase end ``` -If your Capybara configuration requires more setup than provided by Rails, all -of that configuration can be put into the `application_system_test_case.rb` file. +If your Capybara configuration requires more setup than provided by Rails, this +additional configuration could be added into `application_system_test_case.rb` +file. Please see [Capybara's documentation](https://github.com/teamcapybara/capybara#setup) for additional settings. @@ -695,9 +694,9 @@ take a screenshot of the browser. Now we're going to add a system test to our blog application. We'll demonstrate writing a system test by visiting the index page and creating a new blog article. -If you used the scaffold generator, a system test skeleton is automatically -created for you. If you did not use the generator start by creating a system -test skeleton. +If you used the scaffold generator, a system test skeleton was automatically +created for you. If you didn't use the scaffold generator, start by creating a +system test skeleton. ```bash $ bin/rails generate system_test articles |