Merge pull request sarven#2 from bueltge/main

Small grammar corrections.

Author: sarven

README.md

@@ -2,11 +2,11 @@
 
 ## Introduction
 
-In these times the benefits of writing unit tests are huge.
+In these times, the benefits of writing unit tests are huge.
 I think that most of the recently started projects contain any unit tests.
 In enterprise applications with a lot of business logic, unit tests are the most important tests,
 because they are fast and can us instantly assure that our implementation is correct.
-However, I often see a problem with good tests in projects, though the benefits of these tests are only huge when you have good unit tests.
+However, I often see a problem with good tests in projects, though these tests' benefits are only huge when you have good unit tests.
 So in these examples, I will try to share some tips on what to do to write good unit tests.
 
 ## Table of Contents
@@ -42,8 +42,6 @@ So in these examples, I will try to share some tips on what to do to write good
 18. [100% Test Coverage shouldn't be the goal](#100-test-coverage-shouldnt-be-the-goal)
 19. [Recommended books](#recommended-books)
 
-## Introduction
-
 ## Test doubles
 
 Test doubles are fake dependencies used in tests.
@@ -171,7 +169,7 @@ $mailer
 ```
 
 :exclamation: 
-To verify incoming interactions use a stub, but to verify outcoming interactions use a mock. 
+To verify incoming interactions, use a stub, but to verify outcoming interactions, use a mock. 
 More: [Mock vs Stub](#mock-vs-stub)
 
 ## Naming
@@ -254,9 +252,9 @@ If your code is just a utility one it's less important.
 If there is a project with complex domain logic, this logic must be very clear for everyone, 
 so then tests describe domain details without technical keywords, and you can talk with a business in a language like in these tests.
 
-All code that is related to the domain should be free from technical details. A non-programmer won't be read these tests, 
-but if you want to talk about the domain these tests will be useful to know what this domain does. 
-There will be a description without technical details e.g. returns null, throws an exception, etc. 
+All code that is related to the domain should be free from technical details. A non-programmer won't be read these tests. 
+If you want to talk about the domain these tests will be useful to know what this domain does. 
+There will be a description without technical details e.g., returns null, throws an exception, etc. 
 This kind of information has nothing to do with the domain, so we shouldn't use these keywords.
 
 
@@ -339,10 +337,9 @@ final class ExampleTest
 
 ## Parameterized test
 
-The parameterized test is a good option to test the SUT with a lot of parameters without repeating the code.  
+The parameterized test is a good option to test the SUT with many parameters without repeating the code.  
 
-:thumbsdown: This kind of test is less readable. To increase the readability a little, negative and positive examples should be
-split up to different tests.
+:thumbsdown: This kind of test is less readable. To increase the readability a little, negative and positive examples should be split up to different tests.
 
 ```php
 final class ExampleTest extends TestCase
@@ -453,7 +450,7 @@ final class TestExample extends TestCase
 
 [TODO]
 
-## Mock vs Stub
+## Mock vs. Stub
 
 Example: 
 ```php
@@ -675,7 +672,7 @@ an infrastructure code related to a file system.**
 
 :heavy_check_mark: Good:
 
-Like in the functional architecture we need to separate a code that has side effects and code which contains only logic.
+Like in functional architecture, we need to separate a code with side effects and code that contains only logic.
 
 ```php
 final class NameParser
@@ -758,7 +755,7 @@ final class ValidUnitExampleTest extends TestCase
 }
 ```
 
-## Observable behavior vs implementation details
+## Observable behavior vs. implementation details
 
 :x: Bad:
 
@@ -957,8 +954,8 @@ final class ValidTestExample extends TestCase
 ```
 
 :information_source: The first subscription model has a bad design. To invoke one business operation you need to call three methods. Also using getters to verify operation is not a good practice.
-In this case, it's skipped checking a change of modifiedAt, probably setting specific modifiedAt during a renew operation can be tested with an expiration business operation. The getter for modifiedAt is not required.
-Of course, there are cases where finding the possibility to avoid getters provided only for tests will be very hard, but always we should try to not introduce them.
+In this case, it's skipped checking a change of `modifiedAt`, probably setting specific `modifiedAt` during a renew operation can be tested with an expiration business operation. The getter for `modifiedAt` is not required.
+Of course, there are cases where finding the possibility to avoid getters provided only for tests will be very hard, but always we should try not to introduce them.
 
 ## Unit of behavior
 
@@ -1213,7 +1210,7 @@ class SubscriptionTest extends TestCase
 }
 ```
 
-:exclamation: **Do not write code 1:1, 1 class : 1 test. It leads to fragile tests which make that refactoring is very hard.**
+:exclamation: **Do not write code 1:1, 1 class : 1 test. It leads to fragile tests which make that refactoring is tough.**
 
 :heavy_check_mark: Good:
 
@@ -1689,7 +1686,7 @@ final class TestUserRepository extends TestCase
 }
 ```
 
-:exclamation: Testing repositories in that way leads to fragile tests and then refactoring is very hard. To test repositories write integration tests.
+:exclamation: Testing repositories in that way leads to fragile tests and then refactoring is tough. To test repositories write integration tests.
 
 ## Test fixtures
 
@@ -1891,8 +1888,7 @@ final class ValidTest extends TestCase
 ```
 
 :exclamation: Adding additional production code (e.g. getter getCustomerType()) only to verify the state in tests is a bad practice.
-It should be verified by another domain significant value (in this case getPercentageDiscount()). Of course, sometimes it can be very hard
-to find another way to verify the operation, and we can be forced to add additional production code to verify correctness in tests, but we should try to avoid that.
+It should be verified by another domain significant value (in this case getPercentageDiscount()). Of course, sometimes it can be tough to find another way to verify the operation, and we can be forced to add additional production code to verify correctness in tests, but we should try to avoid that.
 
 ### Leaking domain details
 
@@ -2210,7 +2206,7 @@ final class ValidTest extends TestCase
 
 ### Time as a volatile dependency
 
-:information_source: The time is a volatile dependency because is non-deterministic, each invocation returns a different result.
+:information_source: The time is a volatile dependency because it is non-deterministic. Each invocation returns a different result.
 
 :x: Bad: