change wording

pages/en/lb4/Testing-your-application.md

@@ -23,7 +23,7 @@ We encourage writing tests from a few perspectives, mainly [black-box testing](h
 For an introduction to automated testing, see [Define your testing strategy](Defining-your-testing-strategy.html); for a step-by-step tutorial, see [Incrementally implement features](Implementing-features.html).
 
 {% include important.html content="
-A great test suite requires you to think smaller and favor fast, focused unit tests over slow application-wide end-to-end tests.
+A great test suite requires you to think smaller and favor fast and focused unit tests over slow end-to-end tests.
 " %}
 
 This article is a reference guide for common types of tests and test helpers.
@@ -45,8 +45,9 @@ integrates these packages and makes them easy to use together with LoopBack.
 
 LoopBack applications that have been generated by `lb4 app` or `lb4`
 from `@loopback/cli` come with `@loopback/testlab` as a
-developer dependency along with `mocha` (available through a CLI prompt;
-enabled by default) so no other setup of testing infrastructure is needed.
+developer dependency along with `mocha` (which is available through a CLI
+prompt and enabled by default) so no other setup of testing infrastructure
+is needed.
 
 ### Setup testing infrastructure manually
 
@@ -330,11 +331,11 @@ describe('Person (unit)', () => {
 });
 ```
 
-Writing a unit test for a custom repository methods is not as straightforward because `CrudRepository` is based on legacy [loopback-datasource-juggler](https://github.com/strongloop/loopback-datasource-juggler) that was not designed with dependency injection in mind. Instead, use integration tests to verify the implementation of custom repository methods; see [Test your repositories against a real database](#test-your-repositories-against-a-real-database) in [Integration Testing](#integration-testing).
+Writing a unit test for a custom repository methods is not as straightforward because `CrudRepository` is based on legacy [loopback-datasource-juggler](https://github.com/strongloop/loopback-datasource-juggler) which was not designed with dependency injection in mind. Instead, use integration tests to verify the implementation of custom repository methods; see [Test your repositories against a real database](#test-your-repositories-against-a-real-database) in [Integration Testing](#integration-testing).
 
 ### Unit test your Sequence
 
-While it's possible to test a custom Sequence class in isolation, it's better to rely on acceptance-level tests in this exceptional case. The reason is that a custom Sequence class typically has many dependencies (which makes test setup too long and complex), and at the same time it provides very little functionality on top of the injected sequence actions. Bugs are much more likely to be caused by the way the real sequence action implementations interact together (which is not covered by unit tests), instead of the Sequence code itself (which is the only thing covered).
+While it's possible to test a custom Sequence class in isolation, it's better to rely on acceptance-level tests in this exceptional case. The reason is that a custom Sequence class typically has many dependencies (which can make test setup too long and complex), and at the same time it provides very little functionality on top of the injected sequence actions. Bugs are much more likely to be caused by the way the real sequence action implementations interact together (which is not covered by unit tests), instead of the Sequence code itself (which is the only thing covered).
 
 See [Test Sequence customizations](#test-sequence-customizations) in [Acceptance Testing](#acceptance-end-to-end-testing).