Proofing chapter 7 (#25)

Author: kakulgupta

7-testing/7.0-intro.md

@@ -1,32 +1,33 @@
 # Testing
 
-With the growing complexities of apps, unit testing is a mandate. Since we are writing code in JS, we can utilize most of the testing frameworks/libraries available out there for `react/web` apps without much changes.
+With the growing complexities of applications, unit testing becomes mandatory. Since we are writing code in JS, we can utilize most of the testing frameworks/libraries available for `React/web` apps without requiring many changes.
 
-> We recommend using Jest Framework plus some additional utilities like enzyme to make the developer's life easier.
+> We recommend using the Jest Framework plus some additional utilities like Enzyme to make a developer's life easier.
 
 ### What's the use of testing UI code?
 
-We all have asked/been asked this question at least once. And agree or not, the term unit testing was not very popular amongst FE developers until recent years. Here are some of the reasons why we should write unit tests.
+We all have asked or been asked this question at least once while working on frontend. And until recent years, the term unit testing was not very popular among FE developers. Here are some of the reasons why we should write unit tests for FE code.
 
 - It lets you capture bugs before the QA team does:
 
-    We all know that its difficult for a QA and a dev to be friends. No dev likes it when QA team finds a bug and tells them to change it. If your code has a good test coverage, there are very less chances to find bugs. Win-win for both sides right?
+    We all know that it is difficult for a QA and a dev to live in harmony. Devs do not like it when the QA team finds bugs in their work and tells them to make changes. If your code has a good test coverage, there are fewer chances of finding bugs. That's a win-win situation for both sides right?
 
-- Helps other devs understand your code better.
+- Helps other devs understand your code better:
 
-    All the test frameworks have describe block where you define what a method does in a language which any human can understand. Need I say more?
+    All the test frameworks have a `describe` block where you define what the method is supposed to do, just how you would write comments for your code.
 
 - Refactors your code:
 
-    You will start asking these questions to yourself while coding: *How will I test this code?*, *How do I make sure that each method I wrote can be tested?* If you already ask this questions while writing code, then you are one of the few gems.
+    You will start asking these questions to yourself while coding: *How will I test this code?*, *How do I make sure that each method I write can be tested?* If you already ask these questions while writing code, then you are among a small minority of developers.
+
 - Makes your code modular:
 
-    If your code is tested, there are 99% chances that it is modular, which means that you can easily implement changes in future.
+    If your code is tested, there are 99% chances that it is modular, which means that you can easily implement changes in the future.
 
-- Makes debugging/implementing changes much, *much* easier :
+- Makes debugging/implementing changes much, *much* easier:
 
-    There will be cases when you will be required to change a functions logic. *eg, a currency formatter function which return a string.* One way of debugging it would be to go through the UI and check if the desired output is there. Another *smart* way would be to fire your test case, change the test results according to your desired output and __let the test fail__. Now change the logic inside your method to make failed the test pass.
+    There will be cases when you will be required to change a function's logic, *e.g., a currency formatter function which returns a string.* One way of debugging it would be to go through the UI and check if the desired output is showing up. Another *smart* way would be to fire your test cases, change the test results according to your desired output and __let the test fail__. Now change the logic inside your method to make the failed test pass.
 
-- Does __NOT__ increase the dev time:
+- Does __NOT__ increase development time:
 
-    Many of us give this excuse that writing test cases will increase the dev time(Even I used to do this). But believe me it doesn't. During the course of development almost half of the time is spent in debugging/bug fixing .Writing unit tests can decrease the this value from 50% to less than 20%.
+    Many of us give the excuse that writing test cases will increase the development time (even I was of the same opinion). But believe me, it doesn't. During the course of development, almost half of the time is spent in debugging/bug fixing. Writing unit tests can decrease this time from 50% to less than 20%.

7-testing/7.1-jest-setup.md

@@ -1,15 +1,15 @@
 # Jest setup
 
-For all who have not heard about jest, have a quick look here: https://facebook.github.io/jest/
+For all those who have not heard about Jest, have a quick look here: https://facebook.github.io/jest/
 
->Jest is used by Facebook to test all JavaScript code including React applications. One of Jest's philosophies is to provide an integrated "zero-configuration" experience. We observed that when engineers are provided with ready-to-use tools, they end up writing more tests, which in turn results in more stable and healthy code bases.
+>Jest is used by Facebook to test all JavaScript code including React applications. One of Jest's philosophies is to provide an integrated, "zero-configuration" experience. We observed that when engineers are provided with ready-to-use tools, they end up writing more tests, which in turn results in more stable and healthy codebases.
 
 We used Jest because of the following reasons:
 
-- Minimal Configuration.
-- Watch only changed files.
+- Minimal configuration
+- Watches only changed files
 - Fast
-- Snapshot testing(Explained later)
+- Snapshot testing (explained later)
 - Coverage out of box
 
 ### 4 important test scripts every project should have
@@ -24,19 +24,19 @@ We used Jest because of the following reasons:
 ```
 
 - `test`: It will go through all the test files and execute them. This command will also be used in pre-hooks and CI checks.
-- `test:watch`: This will watch all the test files. It is very useful while writing tests and quickly see the result.
+- `test:watch`: This will watch all the test files. It is very useful while writing tests and quickly seeing results.
 - `test:update`: This command will update snapshots for all the presentational components. If the snapshot is not there, it will create it for you. We will discuss snapshots in detail in coming chapters.
 - `coverage`: As the name suggests, this command will generate a coverage report.
 
 
 ### Testing conventions:
 
-It is highly recommended to have conventions for test files as well. Here are the conventions we followed:
+It is highly recommended to have conventions for test files as well. Here are the conventions we follow:
 
-- Jest recommends having a `__test__` folder in the same location the file which is to be tested is placed.
-- The name convention for test file is `<testFileName>.test.js`.
-if you are writing test for `abc.component.js`, then the test filename would be `abc.component.test.js`.
-- In each `expect`, we write the function name first which is to be tested.
+- Jest recommends having a `__test__` folder in the same directory as the file to be tested.
+- The naming convention for test files is `<testFileName>.test.js`.
+If you are writing tests for `abc.component.js`, then the test filename would be `abc.component.test.js`.
+- In each `expect`, we first mention the function name which is to be tested.
 
 Here is a small example following the above mentioned conventions:
 ```js
@@ -49,11 +49,11 @@ describe('counter: Should increment the passed value', () => {
 });
 ```
 
-### JEST configuration:
+### Jest configuration:
 
-As we read in the documentation, Jest is indeed very easy to setup. You do not need  a separate config file, the configuration is so simple that it can fit inside `package.json` only.
+As we read in the documentation, Jest is indeed very easy to set up. You do not need  a separate config file. The configuration is so simple that it can fit inside `package.json`.
 
-Here is our jest config:
+Here is our Jest config:
 ```json
 "jest": {
     "preset": "react-native",
@@ -74,13 +74,13 @@ Here is our jest config:
 
 - `preset`: The preset is a node environment that mimics the environment of a React Native app. Because it doesn't load any DOM or browser APIs, it greatly improves Jest's startup time.
 
-- `cacheDirectory`: It helps you greatly improve the test speed. It does so by creating cache of compiled modules so that next time it doesn't have to compile the node_modules while running tests.
+- `cacheDirectory`: It helps you greatly improve the test speed. It does so by creating a cache of compiled modules so that it doesn't have to compile the node_modules every time we run tests.
 
-- `coveragePathIgnorePatterns`: Define the files which want to skip for coverage reports.
+- `coveragePathIgnorePatterns`: Defines the files which we want to skip while generating coverage reports.
 
-- `coverageThreshold`: Defines the threshold limit for all the tests to pass. If the coverage is less than the defined limit, the tests would fail. This helped us to keep a good amount of coverage at all point of time.
+- `coverageThreshold`: Defines the threshold limit for all the tests to pass. If the coverage is less than the defined limit, the tests would fail. This helped us in keeping code coverage high throughout development.
 
-- `transformIgnorePatterns`: We pass all the NPM modules here which needs to be transpiled. These modules are basically ES6/7 modules.
+- `transformIgnorePatterns`: All the npm modules which need to be transpiled are added here. These modules are basically ES6/7 modules.
 
 _Note: Make sure to add `cache` and `coverage` in your gitignore file._
 

7-testing/7.2-snapshots.md

@@ -1,10 +1,10 @@
 # Snapshots
 
-This features makes testing presentational components a lot easier. With a single line, you can test all your presentational components (their render method only). No need to write test cases for each component returned by render method.
+This feature makes testing presentational components a lot easier. With a single line, you can test all your presentational components (their `render` method only). There is no need to write test cases for each component returned by `render` method.
 
 ### What are Snapshots:
 
-A snapshot is nothing but a configuration file defining your component style, UI and props. The test case will look somthing like this:
+A snapshot is nothing but a configuration file defining your component style, UI, and props. The test case will look something like this:
 
 >\_\_tests__/someComponent.component.test.js
 
@@ -23,7 +23,7 @@ describe('Some component', () => {
 });
 ```
 
-Whenever Jest sees this line `expect(tree).toMatchSnapshot();`, it is going to generate a snapshot and compare it with stored snapshot. If the snapshot is not present, Jest will store the generated snap.
+Whenever Jest sees this line `expect(tree).toMatchSnapshot();`, it is going to generate a snapshot and compare it with the previously stored snapshot. If the snapshot is not present, Jest will store the generated snap.
 
 The generated snap file will look something like this:
 
@@ -64,15 +64,15 @@ As you can see above, the snap contains every possible property of the UI which
 
 ### Should I push generated snaps to git?
 
-Yes you should. Snaps should be there in each dev's machine so that if one of the devs changes some other component unknowingly, the snap test for that component will fail and he/she would know before pushing it.
+Yes, you should. Snaps should be there in each dev's machine so that if one of the devs changes some component unknowingly, the snap test for that component will fail and he/she would know before pushing it.
 Even the Jest official documentation says this:
 
 >It is expected that all snapshots are part of the code that is run on CI and since new snapshots automatically pass, they should not pass a test run on a CI system. It is recommended to always commit all snapshots and to keep them in version control.
 
-### What to do when snap test fails?
+### What to do when a snap test fails?
 
-Consider this scenario. You worked on a component, generated a snap and pushed it. Later another dev named John made some change in the component. Now the test of the snap will fail since snap still contains the code which you wrote. John will just need to update the snapshot to make the test pass. No need to update the test case, just one command: `jest --updateSnapshot` and you are done.
+Consider this scenario: you worked on a component, generated a snap and pushed it. Later, another dev named John made some changes in the component. Now the test of the snap will fail since the snap still contains the code which you wrote. John will just need to update the snapshot to make the test pass. All that is needed to update the test case is one command: `jest --updateSnapshot` and he is done.
 
-*We recommend creating an __npm script__ for updating snaps. As you can see in the package.json of our boiler plate,  it contains a command called "test:update". This command goes through all the test cases and will update the snap whenever it is required.*
+*We recommend creating an __npm script__ for updating snaps. As you can see in the package.json of our boilerplate, it contains a command called "test:update". This command goes through all the test cases and will update the snap whenever it is required.*
 
 __More information can be found here:__ [https://facebook.github.io/jest/docs/en/snapshot-testing.html#content](https://facebook.github.io/jest/docs/en/snapshot-testing.html#content)

7-testing/7.3-enzyme-testing.md

@@ -1,18 +1,18 @@
 # Testing stateful components using Enzyme
 
-We talked about testing presentational components using our beloved feature called Snaphot testing in Jest. But It just tests the UI of the component(just the render method of your component).
+We talked about testing presentational components using our beloved feature Snapshot testing in Jest. But it only tests the UI of the component (the render method).
 
 _What if your component contains some class methods? What if your component contains state?_
 
-Thats where we use __enzyme__.
+That's where we use __Enzyme__.
 
-### What's enzyme?
+### What's Enzyme?
 
-Enzyme is a JavaScript Testing utility for React. You will mostly be using shallow utility from enzyme. Shallow utility helps us rendering a component and allows us accessing the class methods/state of the component.
+Enzyme is a JavaScript testing utility for React. You will mostly be using the `shallow` utility from Enzyme. Shallow utility helps us in rendering a component and allowing us access to the class methods/state of the component.
 
 ### Integrating Enzyme in your current Jest Framework
 
-The default react-native boilerplate comes with Jest. Integrating enzyme with Jest is just a two step process.
+The default react-native boilerplate comes with Jest. Integrating Enzyme with Jest is just a two-step process.
 
 - Install enzyme, jest-enzyme, enzyme-adapters `yarn add enzyme jest-enzyme enzyme-adapter-react-16 enzyme-react-16-adapter-setup --dev`
 
@@ -31,11 +31,11 @@ The default react-native boilerplate comes with Jest. Integrating enzyme with Je
     }
   ```
 
-Thats it. You can start using Enzyme utilities now.
+That's it. You can start using Enzyme utilities now.
 
-### Using Shallow renderer from enzyme:
+### Using Shallow renderer from Enzyme:
 
-- First we need to shallow render our component.
+First, we need to shallow render our component.
 
 ```js
 import {shallow} from 'enzyme';
@@ -46,7 +46,7 @@ describe('SomeComponent component', () => {
 });
 ```
 
-Now Our component is rendered and we can access props/state/methods using `wrapper`. Here is how you access them:
+Now, our component is rendered and we can access props/state/methods using `wrapper`. Here is how you can access them:
 
 
 ```js
@@ -68,12 +68,12 @@ describe('SomeComponent component', () => {
 });
 ```
 
-As you saw, you can access everything a component possess using shallow utitity. You can also have a look at the example test case in our boilerplate code [here]().
+As you can see, you can access everything a component possesses using shallow utitity. You can also have a look at the example test case in our boilerplate code [here]().
 
 
 ### Example
 
-Lets take an example of a component with state and class method. We will write test case for the methods including snapshot test. The example includes testing class methods, state and props.
+Let's take an example of a component with state and class methods. We will write test cases for the methods including a snapshot test. The example includes testing class methods, state, and props.
 
 ```js
 import React from 'react';