Skip to main content

Testing

Communication Tests​

  • The memory based queueing tests can be run without any configuration

Cache Tests​

SQL​

Some cache tests require access to an sql server with rights to create and drop database: Add

{
    "SqlMasterConnection": "Data Source=(localdb)\MSSQLLocalDB;Integrated Security=true"
}

to the user secrets for the /src/tests/common.unit/Common.Cache.UnitTests/ project. Do not specify the database in the connection string.

User secrets can be accessed by right-clicking the project and selecting "Manage User Secrets"

Redis​

Cache tests with a redis backend are only enabled when at least the redis server endpoint is configured: Add

{
    "RedisEndPoint": "localhost:YOUR-CONFIGURED-REDIS-PORT",
    "RedisPassword": "YOUR-REDIS-PW"
}

to the user secrets of the /src/tests/common.unit/Common.Cache.UnitTests/ project.

Please use a redis server dedicated for the dcc tests, since that the current test will flush the default database. A good idea is to simply spin up a redis docker container.

Test payload​

The info here is supposed to help perform a short manual test of a running Api+Backend configuration.

Test request: Distance​

Send a request POST /api/v0/Distance with parameter roadNetId set to the current id for Denmark (probably 'DK', use the roadnets endpoint GET /api/v0/roadnets to verify) and the following json request body:

{
    "source": {
        "latitude": 55.477123,
        "longitude": 8.446984
    },
    "destinations": [
      {
          "latitude": 55.478828,
          "longitude": 8.483446
      }
    ]
}

Test request: Trace​

Send a request POST /api/v0/Trace with parameter roadNetId set to the current id for Denmark (probably 'DK', use the roadnets endpoint GET /api/v0/roadnets to verify) and the following json request body:

{
    "source": {
        "latitude": 55.477123,
        "longitude": 8.446984
    },
    "destination": {
        "latitude": 55.478828,
        "longitude": 8.483446
    }
}

Load testing​

Load testing is done with K6.io.

The tests are located under /src/tests/load directory.

Tests can be executed manually or via a pipeline gdcc_load_tests.

To run tests manually:

  • Install k6 via chocolatey choco install k6 -y
  • Run k6 run -e API_PASSWORD="%gdcc_password%" -e BASE_URL="https://gdcc-dev.amcsplatform.com" -e API_USER="gdcc" simple-example.js from src/tests/load directory.

Integration tests​

Integrations tests can be found in /src/tests/integration/GlobalDcc.IntegrationTests. The tests are started from Test Explorer in Visual Studio. All the tests share an API and a Road Net Manager, but each test fixture has their own backend(s).

When starting a test run the following happens:

  • The framework starts containers for the shared resources: API, Road Net Manager, Dapr sidecars for API and Road Net Manager, Redis, and RabbitMQ (if running with UseAzure set to false).
  • The tests are started. Each test fixture start containers for one or more Backends and their Dapr sidecar(s). When all tests in the fixture are finished these containers are removed.
  • When the test run is finished, it starts a clean up script. This is done when the assembly is unloaded, and since we only have 3 seconds to run anything then and the clean up might take more than that, we run it in a script in a separate process.

Test logs​

The API, Backends, and Road Net Manager write their logs to the folder /src/tests/integration/GlobalDcc.IntegrationTests/TestLogs. The other containers logs can be founf in Docker Desktop or VS's Containes window, while the container is running. When these containers are removed, their logs are gone.

Configuration​

The project has one setting UseAzure, which is set in /src/tests/integration/GlobalDcc.IntegrationTests/appsettings.json. This setting controls whether Dapr uses Azure or local resources for State and PubSub.

If UseAzure is set to false the tests will use local resources (Redis and RabbitMQ) for Dapr State and PubSub.

If UseAzure is set to true the tests will use Azure resources (Service Bus and Storage) for Dapr State and PubSub. To use these you need access to an Azure Service Bus and an Azure Storage. The test framework needs the connection string and account key for these in a secrets file /src/tests/integration/GlobalDcc.IntegrationTests/TestData/dapr/Azure/configuration/secrets.json. The following is an example of the content of such a file:

{
  "connections": {
    "ASBConnectionString": "Endpoint=sb://jens-dcc-poc.servicebus.windows.net/;SharedAccessKeyName=XXX_YOUR_VALUE_XXX;SharedAccessKey=XXX_YOUR_VALUE_XXX",
    "AzureStorageAccountKey": "XXX_YOUR_VALUE_XXX"
  }
}

For details on how to find these values see Configuring Caching and Queueing.

You might need to be on AMCS' VPN when using Azure resources.

Adding new tests​

When adding a new test let it extend GlobalDcc.IntegrationTests.Tests.DockerBaseTest, that way it will inherit the functionality used for starting the necessary containers. You will need to override the RoadNetsForBackend dictionary. Each key in this dictionary corresponds to the name of a Backend and its road net. The values in the dictionary are absolute paths to the road net data the backend should use. The keys should be unique (across all test classes) and lower case, it is recommended to use the name of the class with upper case letters replaced by a dash and the lower case letter, except for the first character that should just be changed to lower case.