Apply suggestions from code review

Co-authored-by: Isaac Good <[email protected]>
Co-authored-by: Anastasios Chatzialexiou <[email protected]>

Author: 3 people

using/solving-exercises/tdd.md

@@ -34,23 +34,25 @@ Should you choose to work with a mentor (and we encourage you to do that once yo
 When you're working in the code editor on Exercism's website, you can read the tests but you are not able to edit them.
 All tests will be executed each time you run them, regardless of any "skip" mechanisms noted in the test file.
 
-Test results will default to expanding the first failed test message (although what is displayed varies by track).
+When there are multiple tests that fail, three website initially only displays the results of the first failure.
+You can click on other failures to expand them, too!
+Sometimes the first result may not be the most informative.
 
 Don't be discouraged by a large number of failing tests.
 Focus on making them pass one-by-one.
 
 ## Working locally
 
 Many tracks use "skipped" tests in their test files.
-Initially, only the first test is "active" and the remaining are deactivated (how this happens varies by track).
+Initially, only the first test is "active" and the remaining are inactive (how this happens varies by track).
 When you run the test suite in your environment, only the first test runs.
 We do this to encourage you to follow this workflow:
 
 1. Before adding any new code, run the test suite: you should see a failing test.
 1. Add _just enough_ code to pass the test.
 1. Run the test suite.
 1. If the test still fails, repeat step 2.
-1. Once the test passes, refactor your code as desired, ensuring all the activated tests still pass.
+1. Once the test passes, refactor your code as desired, ensuring all active tests still pass.
    Refactoring might include:
     - removing any duplicated code,
     - spliting long functions into smaller ones
@@ -63,13 +65,13 @@ Once all the tests are passing, congratulations, you have solved the exercise!
 Exactly how tests are "unskipped" (or activated) depends on the track.
 For some tracks, it might be commenting or removing an annotation.
 For some tracks, it might be changing an attribute from true to false.
-Take the time to read [the documentation for your track][track-docs]: it will explain these details.
+Take the time to read [the documentation for your track][track-docs]; it will explain these details.
 
 For tracks that don't skip the tests, applying this workflow may be as straightforward as commenting out the tests and uncommenting them one-by-one.
 
 ## Rationale for Test-Driven Development
 
-While it may seem like "putting the cart before the horse", there are several good reasons why you might want to write unit tests before writing the implementation code:
+While it may seem like "putting the cart before the horse", there are several good reasons why you might want to write unit tests before writing the implementation code.
 
 1. Design.
    It forces you to think first about the design of the **interface** to the code, instead of jumping straight to the implementation.