Fix typos (quii#251)

* Remove duplicated 'the'

* Capitalize I

* fix-typos: Match error name with stacktrace

iteration.md

@@ -129,7 +129,7 @@ _NOTE_ by default Benchmarks are run sequentially.
 
 * Change the test so a caller can specify how many times the character is repeated and then fix the code
 * Write `ExampleRepeat` to document your function
-* Have a look through the [the strings](https://golang.org/pkg/strings) package. Find functions you think could be useful and experiment with them by writing tests like we have here. Investing time learning the standard library will really pay off over time.
+* Have a look through the [strings](https://golang.org/pkg/strings) package. Find functions you think could be useful and experiment with them by writing tests like we have here. Investing time learning the standard library will really pay off over time.
 
 ## Wrapping up
 

maps.md

@@ -524,7 +524,7 @@ We added yet another error type for when the word does not exist. We also modifi
 ```
 ./dictionary_test.go:53:16: dictionary.Update(word, "new test") used as value
 ./dictionary_test.go:64:16: dictionary.Update(word, definition) used as value
-./dictionary_test.go:66:23: undefined: ErrWordDoesNotExists
+./dictionary_test.go:66:23: undefined: ErrWordDoesNotExist
 ```
 
 We get 3 errors this time, but we know how to deal with these.

mocking.md

@@ -602,8 +602,8 @@ This is usually a sign of you testing too much _implementation detail_. Try to m
 It is sometimes hard to know _what level_ to test exactly but here are some thought processes and rules I try to follow:
 
 - **The definition of refactoring is that the code changes but the behaviour stays the same**. If you have decided to do some refactoring in theory you should be able to do make the commit without any test changes. So when writing a test ask yourself
-  - Am i testing the behaviour I want or the implementation details?
-  - If i were to refactor this code, would I have to make lots of changes to the tests?
+  - Am I testing the behaviour I want or the implementation details?
+  - If I were to refactor this code, would I have to make lots of changes to the tests?
 - Although Go lets you test private functions, I would avoid it as private functions are to do with implementation.
 - I feel like if a test is working with **more than 3 mocks then it is a red flag** - time for a rethink on the design
 - Use spies with caution. Spies let you see the insides of the algorithm you are writing which can be very useful but that means a tighter coupling between your test code and the implementation. **Be sure you actually care about these details if you're going to spy on them**