[GitHub] [skywalking] wu-sheng commented on a change in pull request #6849: Refine README.md and backend-oal-scripts.md

[GitBox <gi...@apache.org>]

wu-sheng commented on a change in pull request #6849:
URL: https://github.com/apache/skywalking/pull/6849#discussion_r620905696



##########
File path: docs/en/guides/README.md
##########
@@ -44,113 +44,101 @@ and if you would like to run all the ITs, simply run `./mvnw -Pall,CI-with-IT cl
 
 Please be advised that if you're writing integration tests, name it with the pattern `IT*` so they would only run with the `CI-with-IT` profile.
 
-### End to End Tests (E2E for short)
-Since version 6.3.0, we have introduced more automatic tests to perform software quality assurance, E2E is one of the most important parts.
+### End to End Tests (E2E)
+Since version 6.3.0, we have introduced more automatic tests to perform software quality assurance. E2E is an integral part of it.
 
 > End-to-end testing is a methodology used to test whether the flow of an application is performing as designed from start to finish.
  The purpose of carrying out end-to-end tests is to identify system dependencies and to ensure that the right information is passed between various system components and systems.
 
-The e2e test involves some/all of the OAP server, storage, coordinator, webapp, and the instrumented services, all of which are orchestrated by `docker-compose`,
-besides, there is a test controller(JUnit test) running outside of the container that sends traffics to the instrumented service,
-and then verifies the corresponding results after those requests, by GraphQL API of the SkyWalking Web App.
+The E2E test involves some/all of the OAP server, storage, coordinator, webapp, and the instrumented services, all of which are orchestrated by `docker-compose`. Besides, there is a test controller (JUnit test) running outside of the container that sends traffic to the instrumented service,
+and then verifies the corresponding results after those requests have been made through GraphQL API of the SkyWalking Web App.
 
-Before all following steps, please set the SkyWalking version `sw.version` in the [pom.xml](../../../test/e2e/pom.xml)
-so that you can build it in your local IDE, but please make sure not to check this change into the codebase. However, if
-you prefer to build it in command line interface with `./mvnw`, you can simply use property `-Dsw.version=x.y.z` without
-modifying the pom.xml.
+Before you take the following steps, please set the SkyWalking version `sw.version` in the [pom.xml](../../../test/e2e/pom.xml)
+so that you can build it in your local IDE. Make sure not to check this change into the codebase. However, if
+you prefer to build it in the command line interface with `./mvnw`, you can simply use property `-Dsw.version=x.y.z` without
+modifying `pom.xml`.
 
 #### Writing E2E Cases
 
-- Set up environment in IntelliJ IDEA
+- Set up the environment in IntelliJ IDEA
 
-The e2e test is an separated project under the SkyWalking root directory and the IDEA cannot recognize it by default, right click
-on the file `test/e2e/pom.xml` and click `Add as Maven Project`, things should be ready now. But we recommend to open the directory `skywalking/test/e2e`
-in a separated IDE window for better experience because there may be shaded classes issues.
+The E2E test is a separate project under the SkyWalking root directory and the IDEA cannot recognize it by default. Right click
+on the file `test/e2e/pom.xml` and click `Add as Maven Project`. We recommend opening the directory `skywalking/test/e2e`
+in a separate IDE window for better experience, since there may be shaded classes issues.
 
 - Orchestrate the components
 
-Our goal of E2E tests is to test the SkyWalking project in a whole, including the OAP server, storage, coordinator, webapp, and even the frontend UI(not now),
-in single node mode as well as cluster mode, therefore the first step is to determine what case we are going to verify and orchestrate the 
+The goal of the E2E tests is to test the SkyWalking project as a whole, including the OAP server, storage, coordinator, webapp, and even the frontend UI (not for now), on the single node mode as well as the cluster mode. Therefore, the first step is to determine what case we are going to verify, and orchestrate the 
 components.
  
-In order to make it more easily to orchestrate, we're using a [docker-compose](https://docs.docker.com/compose/) that provides a convenient file format (`docker-compose.yml`)
-to orchestrate the needed containers, and gives us possibilities to define the dependencies of the components.
+To make the orchestration process easier, we're using a [docker-compose](https://docs.docker.com/compose/) that provides a simple file format (`docker-compose.yml`) for orchestrating the required containers, and offers an opportunity to define the dependencies of the components.
 
-Basically you will need:
-1. Decide what (and how many) containers will be needed, e.g. for cluster testing, you'll need > 2 OAP nodes, coordinators like zookeeper, storage like ElasticSearch, and instrumented services;
-1. Define the containers in `docker-compose.yml`, and carefully specify the dependencies, starting orders, and most importantly, link them together, e.g. set correct OAP address in the agent side, set correct coordinator address in OAP, etc.
-1. Write (or hopefully reuse) the test codes, to verify the results is correct.
+Follow these steps:
+1. Decide what (and how many) containers will be needed. For example, for cluster testing, you'll need > 2 OAP nodes, coordinators (e.g. zookeeper), storage (e.g. ElasticSearch), and instrumented services;
+1. Define the containers in `docker-compose.yml`, and carefully specify the dependencies, starting orders, and most importantly, link them together, e.g. set the correct OAP address on the agent end, and set the correct coordinator address in OAP, etc.
+1. Write (or hopefully reuse) the test codes to verify that the results are correct.
 
-As for the last step, we have a friendly framework to help you get started more quickly, which provides annotation `@DockerCompose("docker-compose.yml")` to load/parse and start up all the containers in a proper order,
-`@ContainerHost`/`@ContainerPort` to get the real host/port of the container, `@ContainerHostAndPort` to get both, `@DockerContainer` to get the running container.
+As for the final step, we have a user-friendly framework to help you get started more quickly. This framework provides tge annotation `@DockerCompose("docker-compose.yml")` to load/parse and start up all the containers in the proper order.

Review comment:
       ```suggestion
   As for the final step, we have a user-friendly framework to help you get started more quickly. This framework provides the annotation `@DockerCompose("docker-compose.yml")` to load/parse and start up all the containers in the proper order.
   ```




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org