Merge pull request quii#167 from jossy/master

A few small updates for the last "output" section of " Structs, methods & interfaces"

structs-methods-and-interfaces.md

@@ -528,11 +528,13 @@ Now our tests \(at least the list of cases\) make assertions of truth about shap
 
 Remember earlier when we were implementing `Triangle` and we had the failing test? It printed `shapes_test.go:31: got 0.00 want 36.00`.
 
-We knew this was in relation to `Triangle` because we were just working with it, but what if a bug slipped in to the system in one of 20 cases in the table. How would a developer know which case failed? This is not a great experience for the developer, they will have to manually look through the cases to find out which case actually failed.
+We knew this was in relation to `Triangle` because we were just working with it, but what if a bug slipped in to the system in one of 20 cases in the table? How would a developer know which case failed? This is not a great experience for the developer, they will have to manually look through the cases to find out which case actually failed.
 
-We can change our error message `%#v got %.2f want %.2f`. `%#v` format string will print out our struct with the values in it's field, so the developer can see at a glance the properties that are being tested.
+We can change our error message into `%#v got %.2f want %.2f`. The `%#v` format string will print out our struct with the values in its field, so the developer can see at a glance the properties that are being tested.
 
-One final tip with table driven tests is to use `t.Run`.
+To increase the readability of our test cases further we can rename the `want` field into something more descriptive like `hasArea`.
+
+One final tip with table driven tests is to use `t.Run` and to name the test cases.
 
 By wrapping each case in a `t.Run` you will have clearer test output on failures as it will print the name of the case