Review development guide for MEC#29

### 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:

- 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

2. Copy past the YAML

3. 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.

### Client-side

During the phase of code generation (see [code generation](#generating-server-and-client-side-code)), two stubs of code are generated:

1. The server code

2. The client code (see clause Client SDK)

2. The client code (see clause [Client SDK](#client-sdk))

The code is used to create a test application for the micro-service. This test application can be used either in command line or integrated into the AdvantEDGE testing tool.

The code is used to create a test module or application for the micro-service. 

The test application can be used either in command line or integrated into the AdvantEDGE testing tool.

#### Code organization

2. **Implement tests for unimplemented methods**

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

   The code below is an example of what is expected here:

   ```go

   func TestNotImplemented(t *testing.T) {

      fmt.Println("--- ", t.Name())

      log.MeepTextLogInit(t.Name())

      _, err := sendRequest(http.MethodGet, "/queries/uu_unicast_provisioning_info", nil, nil, nil, http.StatusNotImplemented, ProvInfoUuUnicastGET)

      if err != nil {

         t.Fatalf("Failed to get expected response")

      }

      // TODO Add other unsupported methods

   }

   ```

3. **Implement tests for implemented methods**

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

   A basic test function looks like:

   ```go

   func TestPredictedQosPost(t *testing.T) {

      fmt.Println("--- ", t.Name())

      log.MeepTextLogInit(t.Name())

      /******************************

      * expected response section

      ******************************/

      ...

      expected_predictedQos_str, err := json.Marshal(expected_predictedQos)

      if err != nil {

         t.Fatalf(err.Error())

      }

      fmt.Println("expected_predictedQos_str: ", string(expected_predictedQos_str))

      /******************************

      * request body section

      ******************************/

      ...

      body, err := json.Marshal(testPredictedQos)

      if err != nil {

         t.Fatalf(err.Error())

      }

      fmt.Println("body: ", string(body))

      /******************************

      * request execution section

      ******************************/

      rr, err := sendRequest(http.MethodPost, "/provide_predicted_qos", bytes.NewBuffer(body), nil, nil, http.StatusOK, PredictedQosPOST)

      if err != nil {

         t.Fatalf("Failed to get expected expected")

      }

      var respBody PredictedQos

      err = json.Unmarshal([]byte(rr), &respBody)

      if err != nil {

         t.Fatalf("Failed to get expected response")

      }

      fmt.Println("respBody: ", respBody)

      if rr != string(expected_predictedQos_str) {

         t.Fatalf("Failed to get expected response")

      }

   }

   ```

4. **Executing the tests**

   In the server folder, execute the following command:

      Loading and unloading test scenario have two purposes:

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

      - A scenario is required to execute the test scripts

      - When the test terminates, the scenario shall be terminated 

   3. *** TODO ***

   TODO

### Updating confguration files

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

TODO

      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 test body

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

### Executimg a test campaign

### Executing a test campaign

TODO

## Building the UI for the new service

The procedure to execute the tests is the following:

```sh

$ cd test

$ ./start-ut-env.sh

$ ./run-ut.sh

$ ./stop-ut-env.sh

``` 

TODO

The script `start-ut-env.sh` deployes 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.

## Dockerization