Typo and details

.codespellignore

@@ -6,3 +6,5 @@ leapyears
 leapYears
 falsy
 warmup
+procs
+enumerables

ruby/automated_testing/rspec_part_two_code_sharing.md

@@ -4,7 +4,7 @@
 
 We will once again be working from the `odin_rspec` project we set up in the previous lesson. To get the most out this lesson, please follow along with all the examples.
 
 ### Learning Outcomes
 
 - What is a before hook and what phase of a test should you use it for?
 - What is an after hook and phase of a test should you use it for?
@@ -21,7 +21,7 @@
 
 To see this in action, create a new file in the lib directory of your `odin_rspec` project named `user.rb` and paste the following code into it:
 
 ~~~ruby
 # lib/user.rb
 
 class User
@@ -37,11 +37,11 @@
     age >= 65
   end
 end
 ~~~
 
 Next, create a test file for the user class in the spec directory named `user_spec.rb` and write the following tests for the `User` class to exercise the name, email and age attributes:
 
-~~~ruby
+~~~~ruby
 # spec/user_spec.rb
 
 require "spec_helper"
@@ -74,7 +74,7 @@
   end
 
 end
 ~~~
 
 Run the tests to make sure everything is wired together correctly. We can run just the tests for this user class by passing the test file name to the `rspec` command: `$rspec spec/user_spec.rb` .
 
@@ -84,7 +84,7 @@
 
 In our case, we can include a before hook that will create a new `User` instance and assign that instance to a `@user` instance variable that we can use in each of our tests:
 
 ~~~ruby
 # spec/user_spec.rb
 
 require "spec_helper"
@@ -115,18 +115,18 @@
   end
 
 end
 ~~~
 
 By default, before hooks run *before* each test in the same example group. We can see this a bit more clearly by including a puts statement in our before hook:
 
 ~~~ruby
 # spec/user_spec.rb
 
 before do
   puts "running the before hook"
   @user = User.new("David", "[email protected]", 30)
 end
 ~~~
 
 Now, when we run our tests again we should see "running the before hook" printed to the screen three times, once for each of our tests.
 
@@ -134,7 +134,7 @@
 
 Change the before hook to the following and run the tests. The puts statement will only print once in the terminal, proving the before block was only executed once.
 
 ~~~ruby
 # spec/user_spec.rb
 
 before(:all) do

ruby/automated_testing/test_driven_development.md

@@ -3,6 +3,7 @@
 So far you’ve been learning how to test code that you’ve written, but there’s a popular development process that flips that concept on its head. Rather than writing code, manually testing it until you get it working, then writing a test to make sure it stays working; you can write the test **before** the code, so that you don’t have to waste *any* time manually testing. Test Driven Development is the name of this inverted development process.
 
 ### Learning Outcomes
+
 Look through these now and use them to guide your learning. By the end of this lesson, expect to:
 
 - Learn what Test Driven Development is
@@ -30,6 +31,7 @@ This development cycle is known as red-green-refactor, and it’s at the heart o
 One key aspect of the red-green-refactor cycle that *isn’t* in the name, is that the code you write to go from `red` to `green` should be the **minimum** amount required to pass the test. If you find that the functionality you’re adding actually does *more* than is being tested, that is a sign that your method is likely doing too much, or possibly that your tests aren’t testing all of the right functionality.
 
 #### TDD Examples
+
 Let’s walk through a TDD approach to a basic class.
 
 Given the general problem:
@@ -210,6 +212,7 @@ TODO: Exercise: TDD a value object
 TODO: Exercise: TDD a class that has a collaborator which doesn't exist yet using mocks
 
 ### Additional Resources
+
 This section contains helpful links to other content. It isn't required, so consider it supplemental.
 
 Read ["TDD is Dead. Long Live Testing"](http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html) by DHH for an anti-TDD viewpoint
@@ -218,7 +221,7 @@ Read ["TDD is Dead. Long Live Testing"](http://david.heinemeierhansson.com/2014/
 
 This section contains questions for you to check your understanding of this lesson. If you’re having trouble answering the questions below on your own, review the material above to find the answer.
 
-- What does it mean for code to be test **driven**?
-- List four different advantages of TDD.
-- What is the 3 part development cycle used for TDD?
-- How much code should be written when going from the `red` state to the `green` state of the red-green-refactor cycle?
+- [What does it mean for code to be test **driven**?](#what-is-tdd-and-why-do-it)
+- [List four different advantages of TDD](#what-is-tdd-and-why-do-it)
+- [What is the 3 part development cycle used for TDD?](#what-is-tdd-and-why-do-it)
+- [How much code should be written when going from the `red` state to the `green` state of the red-green-refactor cycle?](#what-is-tdd-and-why-do-it)