Just a few changes - seems to read better to me

docs/guide/test-overview.md

@@ -3,11 +3,10 @@ Testing
 
 Testing is an important part of software development. Whether we are aware of it or not, we conduct testing continuously.
 For example, when we write a class in PHP, we may debug it step by step or simply use echo or die statements to verify
-that implementation works according to our initial plan. In case of web application we're entering some test data in forms
-to ensure the page interacts with us as expected. The testing process could be automated so that each time when we need
-to verify something, we just need to call up the code that do it for us. The code that verifies that result matches what
-we've planned is called test and the process of its creation and further execution is known as automated testing, which
-is the main topic of testing chapters.
+the implementation works according to our initial plan. In the case of a web application, we're entering some test data
+in forms to ensure the page interacts with us as expected. The testing process could be automated so that each time when we need to verify something, we just need to call up the code that does it for us. The code that verifies the result matches
+what we've planned is called test and the process of its creation and further execution is known as automated testing,
+which is the main topic of these testing chapters.
 
 
 Developing with tests
@@ -21,25 +20,25 @@ behavior is achieved.
 The process of developing a feature is the following:
 
 - Create a new test that describes a feature to be implemented.
-- Run new test and make sure it fails. It is expected since there's no implementation yet.
+- Run the new test and make sure it fails. It is expected since there's no implementation yet.
 - Write simple code to make the new test pass.
 - Run all tests and make sure they all pass.
 - Improve code and make sure tests are still OK.
 
-After it's done the process is repeated again for another feature or improvement. If existing feature is to be changed,
+After it's done the process is repeated again for another feature or improvement. If the existing feature is to be changed,
 tests should be changed as well.
 
 > **Tip**: If you feel that you are losing time doing a lot of small and simple iterations, try covering more by your
 > test scenario so you do more before executing tests again. If you're debugging too much, try doing the opposite.
 
-The reason to create tests before doing any implemenation is that it allows you to focus on what do we want to achieve
+The reason to create tests before doing any implemenation is that it allows us to focus on what we want to achieve
 and fully dive into "how to do it" afterwards. Usually it leads to better abstractions and easier test maintenance when
-it comes to feature adjustments in for of less coupled components.
+it comes to feature adjustments or less coupled components.
 
-So to sum up pros of such approach are the following:
+So to sum up the pros of such an approach are the following:
 
-- Keeps you focused on one thing at a time so both planning and implementation are getting better.
-- Results in test-covering more features in greater detail i.e. if tests are OK most probably nothing's broken.
+- Keeps you focused on one thing at a time which results in improved planning and implementation.
+- Results in test-covering more features in greater detail i.e. if tests are OK most likely nothing's broken.
 
 In the long term it usually gives you a good time-saving effect.
 
@@ -49,7 +48,7 @@ In the long term it usually gives you a good time-saving effect.
 When and how to test
 ------------------
 
-While test first approach described above makes sense for long term and relatively complex projects it could be overkill
+While the test first approach described above makes sense for long term and relatively complex projects it could be overkill
 for simpler ones. There are some indicators of when it's appropriate:
 
 - Project is already large and complex.
@@ -64,8 +63,8 @@ There's nothing wrong in creating tests covering behavior of existing implementa
 
 In some cases any form of automated testing could be overkill:
 
-- Project is simple and isn't getting any complex.
-- It's one-time project that's going to be expired.
+- Project is simple and isn't getting anymore complex.
+- It's a one-time project that will no longer be worked on.
 
 Still if you have time it's good to automate testing in these cases as well.