correct grammar and integrate all pages to one story

Author: akanshmurthy

sites/en/testing/additional_concepts.step

@@ -4,28 +4,28 @@ message <<-MARKDOWN
   ### Doubles and stubs
   Doubles are simpler objects that represent objects from your application.
   <div class="console"><pre>
-  post = double(:post)
+  orange = double(:orange)
   </pre>
   </div>
-  If you instantiate that double in your test file, you have access to post in your tests to test with. This is instead of creating an entire Post 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.
+  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>
-  post.stub(:title).and_return("Jelly")
+  orange.stub(:name).and_return("Florida Orange")
   </pre>
   </div>
-  So, when you write a test that calls the title attribute of the post double, you'll always get back the string Jelly. Got it? Good!
+  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 post double from above):
+  For instance (assume you already have the orange double from above):
   <div class="console"><pre>
-  post = spy('post')
-  post.content
-  expect(post).to have_received(:content)
+  orange = spy('orange')
+  orange.name
+  expect(orange).to have_received(:name)
   </pre>
   </div>
-  Obviously, this is a simplified case. Instead of post.content, 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!
+  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!
@@ -37,7 +37,7 @@ 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.
+  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
@@ -53,5 +53,7 @@ RUBY
 message <<-MARKDOWN
   So, if you write any tests in your test files that call the Bitly API, then the response will be whatever you defined above. The test will prevent the actual API request from being made. Pretty cool, huh?
 
-  Awesome, you are now equipped with a license to TEST! Go forth and create doubles, stubs, and spies in your app (at least one of each and have a TA verify).
+  Awesome, you are now equipped with a license to TEST! Go forth and create doubles, stubs, and spies in your app (at least one of each and have a TA verify). And, if you have time for a final challenge (optional), click below...
 MARKDOWN
+
+next_step "final_challenge"

sites/en/testing/final_challenge.step

@@ -0,0 +1,8 @@
+message <<-MARKDOWN
+
+Congratulations! Take a second and give yourself a pat on your back. You've come far, my young padawan. This is the final test (no pun intended haha!) :)
+
+# The final challenge
+Essentially, you will clone a repo (link is below) that has broken tests and fix all the broken tests. The broken tests will consist of a variety of different types of tests, incorporating everything you have learned thus far. Good luck, keep calm, and test on!
+
+MARKDOWN

sites/en/testing/testing_frameworks.step

@@ -1,16 +1,16 @@
 message <<-MARKDOWN
 # What's a testing framework?
-A testing framework is an execution environment for automated tests. Think of it as the set of assumptions that reminds you when you veer away from those assumptions. In short Test frameworks helps teams organize their test suites and in turn
-help improve the efficiency of testing. 
+A testing framework is an execution environment for automated tests. Testing frameworks help teams organize their test suites and in turn
+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.  Mini Test is the default testing framework in Rails 5. However, we will be using the RSpec testing framework instead.
 
 
 # RSpec
 ## How to set up RSpec in Rails
 
-Add rspec-rails to both the :development and :test groups in the Gemfile:
+First, create a new Rails app. Then, add rspec-rails to both the :development and :test groups in the Gemfile:
 
 <div class="console"><pre>
 group :development, :test do
@@ -48,7 +48,7 @@ bundle exec rspec
 </pre>
 </div>
 
-By default the above will run all spec files in the spec directory. 
+By default, the above code will run all spec files in the spec directory.
 
 To run only a subset of these specs use the following command:
 
@@ -67,8 +67,8 @@ bundle exec rspec spec/controllers/post_controller_spec.rb
 1 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)
+4    orange_tree.age
+5    expect(orange_tree.age).to eq(1)
 6  end
 7 end
 </pre>
@@ -92,7 +92,7 @@ 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. 
+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.
 
 <div class="console">
 <pre>

sites/en/testing/types_of_tests.step

@@ -3,62 +3,64 @@ message <<-MARKDOWN
 
   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.
 
-  Take a look at the following Post model in your app:
+  Create the Orange and Tree models in your app so that the model files are something like this:
 
   <div class="console"><pre>
-  class Post < ActiveRecord::Base
-    belongs_to :user
-    has_many :replies
-    validates :title, :user_id, :content, presence: true
+  class Orange < ActiveRecord::Base
+    belongs_to :tree
+    validates :name, :tree_id, presence: true
+  end
+
+  class Tree < ActiveRecord::Base
+    has_many :oranges
+    validates :name, presence: true
   end
   </pre>
   </div>
 
-  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 post should have certain associations and validations. Let's start by writing some model tests also known as unit tests!
+  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!
 MARKDOWN
 
 steps do
   step do
-    message "First, create a post model spec file in the models folder of the spec folder. Type this in the terminal:"
+    message "First, create a orange model spec file in the models folder of the spec folder. Type this in the terminal:"
 
     console_without_message "cd app/spec/models"
-    console_without_message "touch post_spec.rb"
+    console_without_message "touch orange_spec.rb"
   end
   step do
     message "Then, run rspec."
 
     console_without_message "bundle exec rpsec"
 
-    message "You should see some report but no tests exist yet. So, let's add one! Copy the below test, paste it into the post model spec file and then run 'bundle exec rspec' on the terminal again."
+    message "You should see some report but no tests exist yet. So, let's add one! Copy the below test, paste it into the orange model spec file and then run 'bundle exec rspec' on the terminal again."
 
     console_without_message <<-RUBY
     describe 'ActiveRecord associations' do
-      it 'Post belongs to users' do
-        expect(Post.reflect_on_association(:user).macro).to be (:belongs_to)
+      it 'Orange belongs to tree' do
+        expect(Orange.reflect_on_association(:tree).macro).to be (:belongs_to)
       end
     end
     RUBY
 
-    message "Great, now you should see one passing test! That's an example of an association test. Let's modify that test to fail. Then, run 'bundle exec rspec' and see what happens. Cool! Let's revert back to the passing test. And, write another association test for the relationship between the Post model and the Reply model!"
+    message "Great, now you should see one passing test! That's an example of an association test. Let's modify that test to fail. Then, run 'bundle exec rspec' and see what happens. Cool! Let's revert back to the passing test. And, write a has many association test for the relationship between the Tree model and the Orange model!"
 
   end
 end
 
 
 message <<-MARKDOWN
-  On to controller tests! Just like the Post model, assume we have the following controller in our app (the other methods are omitted for brevity):
+  On to controller tests! Just like the Orange model, create the following controller in your app (the other methods are omitted for brevity):
 
   <div class="console"><pre>
-  class PostsController < ApplicationController
-    include PostsHelper
-
+  class OrangesController < ApplicationController
     def index
-      @posts = Post.all
+      @oranges = Orange.all
       render :index
     end
 
     def new
-      @post = Post.new
+      @orange = Orange.new
       render :new
     end
   end
@@ -68,17 +70,17 @@ MARKDOWN
 
 steps do
   step do
-    message "First, create a posts controller spec file in the controllers folder of the spec folder. Type this in the terminal:"
+    message "First, create an orange controller spec file in the controllers folder of the spec folder. Type this in the terminal:"
 
     console_without_message "cd app/spec/controllers"
-    console_without_message "touch posts_controller_spec.rb"
+    console_without_message "touch oranges_controller_spec.rb"
   end
   step do
     message "Then, run rspec."
 
     console_without_message "bundle exec rpsec"
 
-    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 posts controller spec file and then run 'bundle exec rspec' on the terminal again."
+    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 and then run 'bundle exec rspec' on the terminal again."
 
     console_without_message <<-RUBY
     describe '#index' do
@@ -100,26 +102,26 @@ steps do
 end
 
 message <<-MARKDOWN
-  Last but not least: view tests! Below is an short snippet of the Post show HTML page in your app:
+  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>
-Post title: <%= @post.title %>
+Orange title: <%= @orange.name %>
 <br>
 <br>
-Post content: <%= @post.content %>
+Orange tree id: <%= @orange.tree_id %>
 <br>
 HTML
 
 message <<-MARKDOWN
-  So, based on the post you create, the show page should render HTML with the post's title and content. Let's verify that with a few tests.
+  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 "First, create a posts view spec file in the views folder of the spec folder. Type this in the terminal:"
+    message "First, create an oranges view spec file in the views folder of the spec folder. Type this in the terminal:"
 
-    console_without_message "cd app/spec/views/posts"
+    console_without_message "cd app/spec/views/oranges"
     console_without_message "touch show.html.erb_spec.rb"
   end
   step do

sites/en/testing/what_are_tests.step

@@ -1,21 +1,21 @@
 message <<-MARKDOWN
-Tests are ways of testing our code to see if they are performing the way we have intended it behave.
+
+Tests are not exams like the ones you have to take in school. Rather, tests are ways of testing code to see if it is performing the way we expect it to behave. Pretty easy, right?
 
 # Example
- For example, lets say we wanted to create a program that models an orange tree.  Well, what defines an orange tree to us? Is it safe to say that we need at least two objects, an orange object and a tree object? Can our tree mature and bear more fruit at a certain age? Could our oranges ripen and fall from the tree?  Sounds like the list can become lengthy right? Lets stop here for a few minutes and see what we need to fulfill these user stories.  
+ For example, let's say we wanted to create a program that models an orange tree because nature is awesome.  Well, what defines an orange tree to us? Is it safe to say that we need at least two objects, an orange object and a tree object? Can our tree mature and bear more fruit at a certain age? Could our oranges ripen and fall from the tree?  Sounds like the list can become lengthy, right? Let's stop here for a few minutes and see what we need to fulfill these user stories.
 
 # What We Need To Test?
-Remember that we need to model an orange and a tree, so we know that there are two objects that needs to be created.
+Remember that we need to model an orange and a tree. So, we know that there are two objects that need to be created.
 
-We could say that the tree will not bear fruit until it matures at one year of age and then it well bare an X amount of oranges.  We would need a test to test if the tree ages and a test to see if the tree has created an X amount of oranges once it has matured.
- 
-How do we determine if an orange is ripe? Well, we can have oranges age and if it is at least 30 days old, then it will fall from the tree.  We would need to write a test to check for ripeness and a test to check if it falls at ripeness.
+We could say that the tree will not bear fruit until it matures at one year of age and then it will bear X number of oranges. We would need a test to test if the tree ages and a test to see if the tree has created X number of oranges once it has matured.
 
-# Now That We Have Tests
-You could think of tests as a requirement list.  Every time a change is made we want to test to see if our code still meets those requirements. For example, as our program becomes increasingly complex and we want to have our tree to have a certain lifespan, would it make sense for our tree to continue to create oranges after exceeding that lifespan?   
+How do we determine if an orange is ripe? Well, we can have an orange age and if it is at least 30 days old, then it will fall from the tree. We would need to write a test to check for ripeness and a test to check if it falls at ripeness.
 
 # Why Is It Important That We Test?
-For situations like our tree's lifespan is a prime example of why tests are important.  As our program becomes more complex over time the tests tells us that a basic requirement is not fulfilled and needs to be addressed.  Can you imagine looking at pages and pages of code that was written by someone else or many years ago without a way to trace exactly where the bug is?  Tests can help!
+You could think of tests as a requirement list.  Every time a change is made we want to test to see if our code still meets those requirements. For example, as our program becomes increasingly complex and we want to have our tree to have a certain lifespan, would it make sense for our tree to continue to create oranges after exceeding that lifespan?
+
+A situation like our tree's lifespan is a prime example of why tests are important. As our program becomes more complex over time with new code added, the tests tell us that the new code negatively affected prior expectations of the behavior of the code. Tests can help keep the original behavior of the code and prevent new bugs from appearing.
 
 # Test Driven Development
 Test-driven development (TDD) is a development technique where you must first write a test that fails before you write new functional code. TDD is a great way to develop your program! Add a test, run all tests, write code, run tests, and then refactor code!