github.com/tickoalcantara12/micro/v3@v3.0.0-20221007104245-9d75b9bcbab9/test/README.md (about)

     1  # Integration tests
     2  
     3  Use these at your own risk.
     4  
     5  Reasons why you should be careful with running this locally:
     6  * it creates a foobar directory which although is reverted in a defer, defers don't seem to work too well in tests
     7  * it executes go gets from micro run output which might or might not modify your go.mod
     8  
     9  The tests in this folder can be ran with `go test --tags=integration`.
    10  It's not being triggered by `go test`.
    11  
    12  ## Architecture
    13  
    14  Key points:
    15  - tests are being run in parallel, with different micro servers running in different containers
    16  - local `micro run` commands will be executed with different env flags, eg. `micro -env=testConfigReadFromService run .` to connect to the above different servers.
    17  
    18  ## Working with these tests
    19  
    20  Although the tests run in docker, the containers and envs are named so you can easily interact with them. Some useful tricks:
    21  
    22  First, we have to build a local docker image and check out the services repo:
    23  ```
    24  bash scripts/test-docker.sh
    25  bash scripts/checkout-services.sh
    26  ```
    27  
    28  To start a test, cd into the `test` folder and then:
    29  
    30  ```
    31  go clean -testcache && go test --tags=integration  -failfast -v -run TestServerAuth$
    32  ```
    33  
    34  ```
    35  $ docker ps
    36  CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS                                                        NAMES
    37  1e6a3003ea94        micro                  "sh /bin/run.sh serv…"   4 seconds ago       Up 1 second         2379-2380/tcp, 4001/tcp, 7001/tcp, 0.0.0.0:14081->8081/tcp   testServerAuth
    38  ```
    39  
    40  As it can be seen the container name is the same as the test name.
    41  The server output can be seen with `docker logs -f testServerAuth`.
    42  
    43  The tests also add the env into the micro config file:
    44  
    45  ```
    46  $ micro env
    47    local               none
    48  * server              127.0.0.1:8081
    49    platform            proxy.m3o.com
    50    testServerAuth      127.0.0.1:14081
    51  ```
    52  
    53  This means we can also interact with the server running in the container in the following way:
    54  
    55  ```
    56  $ micro -env=testServerAuth status
    57  ```
    58  
    59  The loop script can be used to test for flakiness:
    60  ```
    61  cd test; bash loop.sh
    62  ```
    63  
    64  or to run all tests once:
    65  
    66  ```
    67  go clean -testcache && go test --tags=integration -v ./...
    68  ```
    69  
    70  ## K8s integration tests
    71  
    72  We can run a number of integration tests against a k8s cluster rather than the default runtime implementation. We use a Kind (https://kind.sigs.k8s.io/) cluster to run a local cluster and then run the platform install scripts (with a few minor modifications).
    73  
    74  ### Running locally
    75  
    76  #### Pre-reqs
    77  To run the k8s integration tests locally you need to first install the pre-reqs:
    78  - Kind, https://kind.sigs.k8s.io/
    79  - Helm, https://helm.sh/docs/intro/install/
    80  - cfssl, https://github.com/cloudflare/cfssl
    81  - yq, https://github.com/mikefarah/yq
    82  
    83  #### Running the tests
    84  The tests can then be run:
    85  1. `kind create cluster` - create the cluster
    86  2. `./scripts/kind-launch.sh` - install micro in to the cluster
    87  3. `cd test && go clean -testcache && IN_TRAVIS_CI=yes go test --tags=integration,kind -v -run ./...` - run the tests
    88  
    89  #### Adding more tests
    90  Not all integration tests use a server so only a subset of the tests need to run against our Kind cluster. New tests should be defined in the usual way and then added to the `testFilter` slice defined near the top of [kind.go](kind.go). This is the list of all tests to be run against Kind. 
    91  
    92  #### Running a local registry
    93  If you prefer not having to push your images to docker hub for them to be pulled down by your Kind cluster, you can run a local registry and build and push your images to it. We have some handy scripts to get it working.
    94  1. `./scripts/kind-local-reg.sh` - install and run a local registry, set up and launch the cluster to use it
    95  2. `./scripts/kind-build-micro.sh` - build and push micro to the local registry
    96  3. `./scripts/kind-launch.sh` - install micro in to the cluster
    97  
    98  When you make any changes you can build and push using `kind-build-micro.sh` and then bounce all the micro pods `kubectl delete po -l micro=runtime` to pick up the new version.