Edits to rails testing curriculum

tjgrathwell · tjgrathwell · commit 492d7f2082fe · 2017-06-05T23:51:30.000-07:00
* minitest is styled `minitest` or maybe `Minitest`,
  but not `Mini Test`
* Fix a lingering `Rspec.describe` -&gt; `RSpec.describe`
* Show ruby source code with ruby syntax highlighting
* Fix some content in types_of_test page that was outside of a 'step'
diff --git a/sites/en/testing/additional_concepts.step b/sites/en/testing/additional_concepts.step
@@ -3,51 +3,55 @@ message <<-MARKDOWN
 
   ### Doubles and stubs
   Doubles are simpler objects that represent objects from your application.
-  <div class="console"><pre>
+
+  ```ruby
   orange = double(:orange)
-  </pre>
-  </div>
+  ```
+
   If you instantiate that double in your test file, you have access to orange in your tests to test with. This is instead of creating an entire Orange model in ActiveRecord. If you need to create many different test objects with different properties, FactoryGirl is a great gem for that purpose and will allow persistence or in-memory object creation, depending on your testing situation.
 
   Stubs can be used to dictate what is returned when a method is called on a double.
-  <div class="console"><pre>
+
+  ```ruby
   orange.stub(:name).and_return("Florida Orange")
-  </pre>
-  </div>
+  ```
+
   So, when you write a test that calls the title attribute of the orange double, you'll always get back the string Florida Orange. Got it? Good!
 
   ### Spies
   With spies, we are not talking about espionage... at least, not in relation to testing :) Spies can be used to verify whether a method was called on an object.
   For instance (assume you already have the orange double from above):
-  <div class="console"><pre>
+
+  ```ruby
   orange = spy('orange')
   orange.name
   expect(orange).to have_received(:name)
-  </pre>
-  </div>
+  ```
+
   Obviously, this is a simplified case. Instead of orange.name, you might have a complicated method that executes many functions internally and that's where spies can come in handy; they can check easily whether one specific method was called. Capiche? Ok, let's keep on trucking!
 
   ### Webmock
   What if your app relies on third-party services or applications, known amongst friends as application programming interfaces or APIs? Well, it seems like APIs should also be tested but should our test suite really be dependent on someone else? NOPE! What if the API goes down? Or is slow? Welcome to the stage: Webmock!
   Webmock is a gem that stubs out external HTTP requests. Once you include the gem, bundle install, and include the below code snippet in your spec helper file (which is included in every test file), you're good to go.
 MARKDOWN
-console_without_message <<-RUBY
-require 'webmock/rspec'
-WebMock.disable_net_connect!(allow_localhost: true)
+
+source_code :ruby, <<-RUBY
+  require 'webmock/rspec'
+  WebMock.disable_net_connect!(allow_localhost: true)
 RUBY
 
 message <<-MARKDOWN
   Then, you can start stubbing out API requests in your spec helper file. Let's write an example for Bitly, a service that shortens long URLs. This may come in handy when you want to provide external links to info pages about the different types of oranges in your orange tree but the links are too long to display on a line.
 MARKDOWN
 
-console_without_message <<-RUBY
-RSpec.configure do |config|
-  config.before(:each) do
-    stub_request(:get, /api.bitly.com.v3.shorten/).
-      with(headers: {'Accept'=>'*/*', 'User-Agent'=>'Ruby'}).
-      to_return(status: 200, body: "stubbed response", headers: {})
+source_code :ruby, <<-RUBY
+  RSpec.configure do |config|
+    config.before(:each) do
+      stub_request(:get, /api.bitly.com.v3.shorten/).
+        with(headers: {'Accept'=>'*/*', 'User-Agent'=>'Ruby'}).
+        to_return(status: 200, body: "stubbed response", headers: {})
+    end
   end
-end
 RUBY
 
 message <<-MARKDOWN
diff --git a/sites/en/testing/testing_frameworks.step b/sites/en/testing/testing_frameworks.step
@@ -4,7 +4,7 @@ A testing framework is an execution environment for automated tests. Testing fra
 help improve the efficiency of testing.
 
 # Types of testing frameworks
-There are many testing frameworks that work great.  Mini Test is the default testing framework in Rails 5. However, we will be using the RSpec testing framework instead.
+There are many testing frameworks that work great. Minitest is the default testing framework in Rails 5. However, we will be using the RSpec testing framework instead.
 
 
 # RSpec
@@ -19,11 +19,11 @@ rails new testapp
 
 Then, add rspec-rails to both the :development and :test groups in the Gemfile:
 
-<div class="console"><pre>
+```ruby
 group :development, :test do
   gem 'rspec-rails', '~> 3.4'
-end</pre>
-</div>
+end
+```
 
 Download and install by running:
 
@@ -70,18 +70,17 @@ bundle exec rspec spec/controllers/post_controller_spec.rb
 
 ## RSpec Basics
 
-<div class="console"><pre>
-1 Rspec.describe Tree do
-2  it "is able to age by 1 year increments" do
-3    orange_tree = Tree.new
-4    orange_tree.age
-5    expect(orange_tree.age).to eq(1)
-6  end
-7 end
-</pre>
-</div>
+```ruby
+RSpec.describe Tree do
+ it "is able to age by 1 year increments" do
+   orange_tree = Tree.new
+   orange_tree.age
+   expect(orange_tree.age).to eq(1)
+ end
+end
+```
 
-The 'describe' and 'it' methods come from rspec-core. The Tree class would be from your code. You can think of 'describe' as a header to describe which class you are testing and 'it' as a string/subheader that states what specifically you are testing in the Tree class. Note: you may or may not need the Rspec in front of the describe depending on your Rspec version.
+The 'describe' and 'it' methods come from rspec-core. The Tree class would be from your code. You can think of 'describe' as a header to describe which class you are testing and 'it' as a string/subheader that states what specifically you are testing in the Tree class. Note: you may or may not need the RSpec in front of the describe depending on your RSpec version.
 
 The last line of the example expresses an expected outcome. If orange_tree.age == 1, then the example passes. If not, it fails with a message like:
 
@@ -98,13 +97,11 @@ Remember in our example on line 5? 'to eq' is a matcher. RSpec has many built-in
 Check out the other built-in matchers!
 https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
 
-# Mini Test
-In case you were curious to see how tests are written in Mini Test. Mini Test also allows you to write tests in 'expectation style' which is very similar to how RSpec tests are written.
+# minitest
+In case you were curious to see how tests are written in minitest. Minitest also allows you to write tests in 'expectation style' which is very similar to how RSpec tests are written.
 
-<div class="console">
-<pre>
+```ruby
 class TestTree < Minitest::Test
-
   def setup
     @orange_tree = Tree.new
     @orange_tree.age
@@ -114,8 +111,7 @@ class TestTree < Minitest::Test
     assert_equal 1, @orange_tree.age
   end
 end
-</pre>
-</div>
+```
 
 To run the test enter the following in Terminal/Command Prompt:
 
diff --git a/sites/en/testing/types_of_tests.step b/sites/en/testing/types_of_tests.step
@@ -1,7 +1,7 @@
 message <<-MARKDOWN
   Now, that you know what tests are, let's discuss the different types of tests!
 
-  In your Rails app, you have models, views, and controllers -> is MVC ringing a bell? :) Well, it should be no surprise that tests can be written for models, views, and controllers.
+  In your Rails app, you have models, views, and controllers. It should be no surprise that tests can be written for models, views, and controllers.
 
   As you learned in the previous section, tests are used to verify that your code is working as expected. So, a couple things we can test right off the bat are that a tree should have certain associations and validations. Let's start by writing some model tests also known as unit tests! This link might come in handy to remember singular vs. plural Rails conventions: https://alexander-clark.com/blog/rails-conventions-singular-or-plural/
 MARKDOWN
@@ -24,19 +24,19 @@ steps do
     message "You will see a report with one pending test. When you generated your Orange model, RSpec also generated a matching spec file. Copy the test below into spec/models/orange_spec.rb and run 'bundle exec rspec' on the terminal again."
 
 
-    console_without_message <<-RUBY
-    RSpec.describe Orange, :type => :model do
-      context 'ActiveRecord associations' do
-        it 'Orange belongs to tree' do
-          expect(Orange.reflect_on_association(:tree).macro).to be (:belongs_to)
+    source_code :ruby, <<-RUBY
+      RSpec.describe Orange, :type => :model do
+        context 'ActiveRecord associations' do
+          it 'Orange belongs to tree' do
+            expect(Orange.reflect_on_association(:tree).macro).to be (:belongs_to)
+          end
         end
       end
-    end
     RUBY
 
     message "Run 'bundle exec rspec'. This test fails! Let's add an associaton to our model. Add a belongs_to association to orange.rb:"
 
-    console_without_message <<-RUBY
+    source_code :ruby, <<-RUBY
     class Orange < ActiveRecord::Base
       belongs_to :tree
     end
@@ -66,20 +66,20 @@ steps do
 
     message "You should see a report with some passing tests but those are just the model tests you wrote. So, let's add some controller tests! Copy the below test, paste it into the oranges controller spec file, create the relevant view files and then run 'bundle exec rspec' on the terminal again."
 
-    console_without_message <<-RUBY
-    RSpec.describe OrangesController do
-      context '#index' do
-        it "renders the index view" do
-          get :index
-          expect(response).to render_template("index")
-        end
-
-        it "renders html" do
-          process :index, method: :get
-          expect(response.content_type).to eq "text/html"
+    source_code :ruby, <<-RUBY
+      RSpec.describe OrangesController do
+        context '#index' do
+          it "renders the index view" do
+            get :index
+            expect(response).to render_template("index")
+          end
+  
+          it "renders html" do
+            process :index, method: :get
+            expect(response.content_type).to eq "text/html"
+          end
         end
       end
-    end
     RUBY
 
     message "You should see two failing tests. You'll need to add a route, index action, and a view. Not sure where to start? Read the errors in your failing tests for a hint. Run 'bundle exec rspec' after each change until both tests pass."
@@ -90,26 +90,25 @@ steps do
   step do
     message "Now, write another controller test for the new action (hint: you might need to look up what a mock is)."
   end
-end
 
-message <<-MARKDOWN
-  Last but not least: view tests! Below is an short snippet of a possible Orange show HTML page you can create in your app:
-MARKDOWN
-console_without_message <<-HTML
-<br>
-Orange title: <%= @orange.name %>
-<br>
-<br>
-Orange tree id: <%= @orange.tree_id %>
-<br>
-HTML
-
-message <<-MARKDOWN
-  So, based on the orange you create, the show page should render HTML with the orange's name and tree id. Let's verify that with a few tests.
-MARKDOWN
-
-steps do
   step do
+    message <<-MARKDOWN
+      Last but not least: view tests! Below is an short snippet of a possible Orange show HTML page you can create in your app:
+    MARKDOWN
+
+    source_code :erb, <<-ERB
+      <br>
+      Orange title: <%= @orange.name %>
+      <br>
+      <br>
+      Orange tree id: <%= @orange.tree_id %>
+      <br>
+    ERB
+
+    message <<-MARKDOWN
+      So, based on the orange you create, the show page should render HTML with the orange's name and tree id. Let's verify that with a few tests.
+    MARKDOWN
+
     message "First, create a views folder in the spec folder. Then, create an oranges folder in the views folder. Lastly, create an oranges view spec file in the oranges folder. Type these commands in the terminal:"
 
     console_without_message "mkdir app/spec/views"
