fix typos and sentence structures in dev guide

### Server stubs

Since the backend of MEC Sandbox (AdvantEDGE) is written in _Go_, the server stubs need to be generated for _Go_ as well. Prerequisite for generate the server stubs for a partiular MEC service is its OpenAPI Specifications (OAS) YAML/JSON file. These files can be accessed on [ETSI Forge](https://forge.etsi.org/rep/mec).

Since the backend of MEC Sandbox (AdvantEDGE) is written in _Go_, the server stubs need to be generated for _Go_ as well. Prerequisite for generate the server stubs for a particular MEC service is its OpenAPI Specifications (OAS) YAML/JSON file. These files can be accessed on [ETSI Forge](https://forge.etsi.org/rep/mec).

[Swagger Codegen](https://github.com/swagger-api/swagger-codegen) is the tool which AdvantEDGE receommends should be used for generating the server stubs from the OAS file. All the MEC service API server stubs were generated using this tool.

[Swagger Codegen](https://github.com/swagger-api/swagger-codegen) is the tool which AdvantEDGE recommends should be used for generating the server stubs from the OAS file. All the MEC service API server stubs were generated using this tool.

However, the OpenAPI Specifications files available on ETSI Forge use version 3.1 of OAS. Currently this version is not supported on Swagger Codegen or on any other OAS code generater. To generate the server stubs, first the OAS files will need to be converted to OAS version 3.0 via the following steps:

However, the OpenAPI Specifications files available on ETSI Forge use version 3.1 of OAS. Currently this version is not supported on Swagger Codegen or on any other OAS code generator. To generate the server stubs, first the OAS files will need to be converted to OAS version 3.0 via the following steps:

- Change the value of `openapi` field from 3.1.0 to 3.0.0​

### Client SDK

The Client SDK source code is generated using [Swagger Codegen](https://github.com/swagger-api/swagger-codegen).

The OpenAPI Specifications files available on ETSI Forge use version 3.1 of OAS. Currently this version is not supported on Swagger Codegen or on any other OAS code generater. To generate the server stubs, first the OAS files will need to be converted to OAS version 3.0 via the following steps:

The OpenAPI Specifications files available on ETSI Forge use version 3.1 of OAS. Currently this version is not supported on Swagger Codegen or on any other OAS code generator. To generate the server stubs, first the OAS files will need to be converted to OAS version 3.0 via the following steps:

- Change the value of openapi field from 3.1.0 to 3.0.0​

- Change the value of `openapi` field from 3.1.0 to 3.0.0​

- Use this VS code extension to see the errors in the downgraded YAML (v3.0)​

- Manually fix the errors​

To generate the server stubs, follow these steps:

1. Open [Swagger Editor](https://editor.swagger.io/);

2. Copy/past the YAML file in the left panel;

3. In the Swagger Editor menu, select 'Generate Client' and 'go';

4. A zip file containing the client stubs will be generated;

5. Unzip the archive into go-package/meep-<MEC identifier>-client folder;

6. Switch to clause [Client-side](#client-side).

> Note: Both Go language and Java language client SDK are generated. The Go client SDK is required to develop the testing tool for the MEC-030 micro-service (see clause Creating test code).

The Java client SDK is required to develop the backend of a MEC application using MEC030 micro-service.

1. Install Java on your system

2. Download the Swagger Codegen v3.0.22 _jar_ file as this version is recommended by AdvantEDGE:

   ```sh

   $ wget https://repo1.maven.org/maven2/io/swagger/codegen/v3/swagger-codegen-cli/3.0.22/swagger-codegen-cli-3.0.22.jar -O swagger-codegen-cli.jar

   ```

3. Run the following command to generate server stubs in _Go_:

   ```sh

   $ java -jar swagger-codegen-cli.jar generate \

     -i oas-file.yaml \

     -l go \

     -o ~/output

   ```

   Here `swagger-codegen-cli.jar` is the downloaded Swagger Codegen _jar_ file, `oas-file.yaml` is the OAS YAML file and `~/output` is the path to the folder where the server stubs will be generated to.

> **Note:** Both server stubs and client SDK are generated using Swagger Codegen. The Go client SDK is required to develop the testing tool for the MEC030 micro-service (see clause [creating test code](#unit-tests-for-the-new-micro-service)). The Go client SDK is required to develop the backend of a MEC application using MEC030 micro-service.

## Development of Emulation Logic

### Server-side

After the server stubs have been generated (see [Server stubs](#server-stubs)), the folder stucture will be something like the structure shown below:

After the server stubs have been generated (see [server stubs](#server-stubs)), the folder structure will be something like the structure shown below:

```

meep-<mec-identifier>

#### Code organization

The organization of the client code follow the AdvantEDGE usage. It is illustrated by the figure below:

The organization of the client code follows the AdvantEDGE usage. It is illustrated by the figure below:

```

go-packages

                    \____ README.md

```

The tag `<mec-identifier>` identifies the MEC API implemented by the micro-service. For instance, for the MEC-030 micro-service,the tag is 'vis'. The client microservice is named mee-vis-client.

The tag `<mec-identifier>` identifies the MEC API implemented by the micro-service. For instance, for the MEC030 micro-service, the tag is 'vis'. The client micro-service is named meep-vis-client.

There may be multiple files for `api_<api_tag>` and `model_<model_name>` depending on the tags and component schemas in the OAS file used to generate the server stubs.

1. **Client package renaming**

   Rename the client package generated by [Swagger Codegen](https://github.com/swagger-api/swagger-codegen) is a package named 'swagger'. This package name shall be renamed into 'client' using the following command:

   The go client package generated by [Swagger Codegen](https://github.com/swagger-api/swagger-codegen) is a package named 'swagger'. This package name is to be renamed to 'client' using the following command:

   ```sh

   $ cd go-packages/meep-<mec-identifier>-client

   $ find . -name "*.go" -exec sed --in-place 's/swagger/client/g' {} \;

2. **Create the service handler file**

   Merge all files named `client/api_*.go` into a singkle file named `client/api_vis.go`

   Merge all files named `client/api_*.go` into a single file named `client/api_<mec-identifier>.go`

3. **Rename generated constants name**

   Sometimes. the Swagger Codegen generates automatic names for constants (e.g. model_transmission_bandwidth_transmission_bandwidth.go). Unfortunately, these names are mot compliant with go language (e.g. 1__TransmissionBandwidthTransmissionBandwidth).

   In this case, it is required to rename them properly (e.g. 1__TransmissionBandwidthTransmissionBandwidth shall renamed into bw6).

   Sometimes. the Swagger Codegen generates automatic names for constants (e.g. model_transmission_bandwidth_transmission_bandwidth.go). Unfortunately, these names are not compliant with go language (e.g. _1__TransmissionBandwidthTransmissionBandwidth_).

   In this case, it is required to rename them properly (e.g. _1__TransmissionBandwidthTransmissionBandwidth_ shall renamed into _bw6_).

4. **Creating _go.mod_ and _go.sum_ files**

1. **Create a testing file**

   Create a file named <mec-identifier>_Test.go

   Create a file named <mec-identifier>_test.go

   The files will look something like the file/folder structure shown below:

```

2. **Implement tests for unimplemented methods**

   For each HTTP methods some tests for valid behavior and unexpected behovior shall be created.

   For each HTTP methods some tests for valid behavior and unexpected behavior should be created.

3. **Implement tests for implemented methods**

   For each HTTP methods some tests for valid behavior and unexpected behovior shall be created.

   For each HTTP methods some tests for valid behavior and unexpected behavior should be created.

4. **Executing the tests**

## Integration tests for the new micro-service

The AdvantEDGE testing tool provides an automatic testing process to validate the AdvantEDGE platform deployment. The purpose of the test scripts developped for each micro-service is to validate the micro-service backend implementation and its integartion into the AdvantEDGE platform.

The AdvantEDGE testing tool provides an automatic testing process to validate the AdvantEDGE platform deployment. The purpose of the test scripts developed for each micro-service is to validate the micro-service backend implementation and its integration into the AdvantEDGE platform.

It is based on [cypress framework](https://www.cypress.io/)

The tests in this case are based on [cypress framework](https://www.cypress.io/).

Steps to implement server side emulation logic:

1. **Updating commands scripts**

   After creating a new micro-service, the following commands scripts shall be updated to add the micro-service descriptions:

   - run-ut.sh

   After creating a new micro-service, the following bash script should be updated to add the micro-service descriptions:

   - _run-ut.sh_

2. **Creating test code**

   Coming with the creation of a micro-services, a go source file hosting the specific test codes and its configuration file shall be created. It contains the test function of each HTT REST API proposed by new micro-services.

   After the micro-service has been created, a _go_ source file in `/AdvantEDGE/test/system` folder will be created containing the code for testing the HTTP REST APIs.

   ```sh

   $ cd ~/AdvantEDGE/test/system

   $ touch vis-interface_test.go

   $ touch vis-interface-system-test.yaml

   $ touch <mec-identifier>-interface_test.go

   $ touch <mec-identifier>-interface-system-test.yaml

   ```

   The file vis-interface_test.go contains the testing functions based on MEC-030 HTTP REST API.

   The file `<mec-identifier>-interface_test.go` contains the testing functions based on MEC service HTTP REST APIs.

   The file vis-interface-system-test.yaml is describe the scenarion used during the test stages.

   The file `<mec-identifier>-interface-system-test.yaml` describes the scenarios used during the test stages.

3. **Implementing the tests**

   The implementation of the MEC-030 test sripts shall cover all the HTTP API entries such as GET, POST...

   1. ***Step1: Initialization***

      The first step is to initialize the test sequence by creating an instance of the micro-service client (see clause Client-side (/go-packages)).

      The first step is to initialize the test sequence by creating an instance of the micro-service client (see clause [client side](#client-side)).

   2. ***Step2: Load and unload scenario***

      Loading and unloading test scenario have two purposes:

      - Verify that integartion of the micro-sevice under test in working properly

      - Verify that integration of the micro-service under test in working properly

      - A scenario is required to execute the test scripts

      - When the test terminates, the scenario shall be terminated

      - When the test terminates, the scenario is being terminated

   3. ***Step3: The test***

      The test can be structured as follows:

      - The preambule where the micro-service is set in a specific state (e.g. create a new subscription)

      - The preamble where the micro-service is set in a specific state (e.g. create a new subscription)

      - The test body

      - The postamble  where the micro-service is set in a idle state (e.g. delete the subscription)

      - The post-processing step where the micro-service is set in a idle state (e.g. delete the subscription)

### Executing a test campaign

The procedure to execute the tests is the following:

```sh

$ cd test

$ ./start-ut-env.sh

$ ./run-ut.sh

$ ./stop-ut-env.sh

cd test

./start-ut-env.sh

./run-ut.sh

./stop-ut-env.sh

```

The script `start-ut-env.sh` deployes the required components to execute the tests against the micro-service.

The script `start-ut-env.sh` deploys the required components to execute the tests against the micro-service.

The script `run-ut.sh` executes all the tests against the different micro-services and components.

The script `stop-ut-env.sh` deletes the components prviously started by `start-ut-env.sh` script.

The script `stop-ut-env.sh` deletes the components previously started by `start-ut-env.sh` script.

## Dockerization

The new feature (MEC service) will run inside a pod as a microservice in AdvantEDGE backend. Therefore, we need to create a Dockerfile to containerize the new MEC service.

The new feature (MEC service) will run inside a pod as a micro-service in AdvantEDGE backend. Therefore, we need to create a Dockerfile to containerize the new MEC service.

### Creating a Dockerfile

1. Make _Dockerfile_ in the the root directory of the new MEC service created [here](#development-of-emulation-logic) which will look like this:

1. Make _Dockerfile_ in the the root directory of the new MEC service (created [here](#development-of-emulation-logic)) which will look like this:

```Dockerfile

# Copyright (c) 2020  InterDigital Communications, Inc

# limitations under the License.

FROM debian:9.6-slim

COPY ./meep-vis /meep-vis

COPY ./meep-vis /meep-<mec-identifier>

COPY ./api /api

COPY ./user-api /user-api

COPY ./data /

exec /meep-<mec-identifier>

```

**NOTE**: Replace `meep-<mec-identifier>` in the last line with the service name. For example, for V2X Information service, it will become `meep-vis`.

> **NOTE**: Replace `meep-<mec-identifier>` with the service name. For example, for V2X Information service, it will become `meep-vis`.

The updated directory tree will look like this:

            \____ <mec-identifier>.go

```

As a next step, code include in the directory structure above will be added into AdvantEDGE repository of fork. See [Code Integration](./backend-integration.md#code-integration) for more details.

As a next step, code included in the directory structure above will be added into AdvantEDGE's fork repository. See [Code Integration](./backend-integration.md#code-integration) for more details.