Updated README files to add code blocks around example Ruby code. Updated Feature files to identify type of code within code blocks.

Author: threeplanetssoftware

features/Generators.md

@@ -10,7 +10,9 @@ out of the box for with Rails' defaults.
 
 RSpec generators can also be run independently. For instance,
 
+```shell
     rails generate rspec:model widget
+```
 
 will create a new spec file in `spec/models/widget_spec.rb`.
 

features/GettingStarted.md

@@ -2,44 +2,62 @@
 
 Install Rails 6
 
+```shell
     $ gem install rails -v "~> 6.0.0"
+```
 
 ### Generate an app
 
+```shell
     $ rails new example_app
     $ cd example_app
+```
 
 ### Add `rspec-rails` to the Gemfile
 
+```shell
     $ echo 'gem "rspec-rails", group: [:development, :test]' >> Gemfile
+```
 
 ### Install the bundle
 
+```shell
     $ bundle install
+```
 
 ### Bootstrap RSpec
 
+```shell
     $ rails generate rspec:install
+```
 
 ### Generate a scaffold
 
+```shell
     $ rails generate scaffold Widget name:string
+```
 
 This generates files in the `app` and `spec` directories. The files in the
 `app` directory are generated by Rails, and Rails delegates the generation of
 the files in the `spec` directory to RSpec.
 
 ### Run migrations
 
+```shell
     $ rails db:migrate && rails db:test:prepare
+```
 
 ### Run RSpec
 
+```shell
     $ rake spec
+```
 
 or
 
+```shell
     $ rspec spec --format documentation
+```
 
 If all went well, you should see output ending with:
 

features/README.md

@@ -15,7 +15,9 @@ for even older versions.
 
 ## Install
 
+```shell
     gem install rspec-rails
+```
 
 This installs the following gems:
 
@@ -29,23 +31,29 @@ This installs the following gems:
 
 Add rspec-rails to the :test and :development groups in the Gemfile:
 
+```ruby
     group :test, :development do
       gem 'rspec-rails', '~> 6.0.0'
     end
+```
 
 It needs to be in the :development group to expose generators and rake tasks
 without having to type RAILS_ENV=test.
 
 Now you can run:
 
+```shell
     bundle exec rails generate rspec:install
+```
 
 This adds the spec directory and some skeleton files, including a .rspec
 file.
 
 You can also customize the default spec path with `--default-path` option:
 
+```shell
     bundle exec rails generate rspec:install --default-path behaviour
+```
 
 ## Issues
 

features/Transactions.md

@@ -3,9 +3,11 @@
 When you run `rails generate rspec:install`, the `spec/rails_helper.rb` file
 includes the following configuration:
 
+```ruby
     RSpec.configure do |config|
       config.use_transactional_fixtures = true
     end
+```
 
 The name of this setting is a bit misleading. What it really means in Rails
 is "run every test method within a transaction." In the context of rspec-rails,
@@ -21,9 +23,11 @@ If you prefer to manage the data yourself, or using another tool like
 [database_cleaner](https://github.com/bmabey/database_cleaner) to do it for you,
 simply tell RSpec to tell Rails not to manage transactions:
 
+```ruby
     RSpec.configure do |config|
       config.use_transactional_fixtures = false
     end
+```
 
 ### Data created in `before(:example)` are rolled back
 
@@ -32,6 +36,7 @@ the example. This is a good thing because it means that each example is
 isolated from state that would otherwise be left around by the examples that
 already ran. For example:
 
+```ruby
     describe Widget do
       before(:example) do
         @widget = Widget.create
@@ -45,6 +50,7 @@ already ran. For example:
         expect(@widget).to do_something_else
       end
     end
+```
 
 The `@widget` is recreated in each of the two examples above, so each example
 has a different object, _and_ the underlying data is rolled back so the data
@@ -60,27 +66,31 @@ guidelines:
 
 1.  Be sure to clean up any data in an `after(:context)` hook:
 
+```ruby
         before(:context) do
           @widget = Widget.create!
         end
 
         after(:context) do
           @widget.destroy
         end
+```
 
-    If you don't do that, you'll leave data lying around that will eventually
-    interfere with other examples.
+If you don't do that, you'll leave data lying around that will eventually
+interfere with other examples.
 
 2.  Reload the object in a `before(:example)` hook.
 
+```ruby
         before(:context) do
           @widget = Widget.create!
         end
 
         before(:example) do
           @widget.reload
         end
+```
 
-      Even though database updates in each example will be rolled back, the
-      object won't _know_ about those rollbacks so the object and its backing
-      data can easily get out of sync.
+Even though database updates in each example will be rolled back, the
+object won't _know_ about those rollbacks so the object and its backing
+data can easily get out of sync.

features/controller_specs/README.md

@@ -42,6 +42,7 @@ To specify outcomes, you can use:
 
 ## Examples
 
+```ruby
     RSpec.describe TeamsController do
       describe "GET index" do
         it "assigns @teams" do
@@ -56,6 +57,7 @@ To specify outcomes, you can use:
         end
       end
     end
+```
 
 ## Views
 
@@ -67,6 +69,7 @@ To specify outcomes, you can use:
 
 We encourage you to use [request specs](./request-specs/request-spec) if you want to set headers in your call. If you still want to use controller specs with custom http headers you can use `request.headers`:
 
+```ruby
     require "rails_helper"
 
     RSpec.describe TeamsController, type: :controller do
@@ -78,3 +81,4 @@ We encourage you to use [request specs](./request-specs/request-spec) if you wan
         end
       end
     end
+```

features/mailer_specs/README.md

@@ -9,6 +9,7 @@ behavior and expectations.
 
 ## Examples
 
+```ruby
     require "rails_helper"
 
     RSpec.describe Notifications, type: :mailer do
@@ -26,3 +27,4 @@ behavior and expectations.
         end
       end
     end
+```

features/matchers/README.md

@@ -5,16 +5,22 @@ rspec-compatible wrappers for Rails' assertions.
 
 ### redirects
 
+```ruby
     # delegates to assert_redirected_to
     expect(response).to redirect_to(path)
+```
 
 ### templates
 
+```ruby
     # delegates to assert_template
     expect(response).to render_template(template_name)
+```
 
 ### assigned objects
 
+```ruby
     # passes if assigns(:widget) is an instance of Widget
     # and it is not persisted
     expect(assigns(:widget)).to be_a_new(Widget)
+```

features/model_specs/README.md

@@ -9,6 +9,7 @@ behavior and expectations.
 
 ## Examples
 
+```ruby
     require "rails_helper"
 
     RSpec.describe Post, type: :model do
@@ -21,3 +22,4 @@ behavior and expectations.
         end
       end
     end
+```

features/request_specs/request_spec.feature

@@ -17,8 +17,10 @@ Feature: Request specs
 
   RSpec provides two matchers that delegate to Rails assertions:
 
+  ```ruby
       render_template # delegates to assert_template
       redirect_to     # delegates to assert_redirected_to
+  ```
 
   Check the Rails docs for details on these methods as well.
 

features/routing_specs/README.md

@@ -7,12 +7,16 @@ Simple apps with nothing but standard RESTful routes won't get much value from
 routing specs, but they can provide significant value when used to specify
 customized routes, like vanity links, slugs, etc.
 
+```ruby
     expect(:get => "/articles/2012/11/when-to-use-routing-specs").to route_to(
       :controller => "articles",
       :month => "2012-11",
       :slug => "when-to-use-routing-specs"
     )
+```
 
 They are also valuable for routes that should not be available:
 
+```ruby
     expect(:delete => "/accounts/37").not_to be_routable
+```