Skip to content

Testserver 101

Jump to bottom
Laurent Mazuel edited this page Mar 20, 2020 · 3 revisions

If you don't know what the autorest testserver is, this is a good place to start :)

Overview

The autorest testserver has for ambition to start a localhost webserver on your machine, that mocks some of the most common scenarios of RestAPI that autorest has to implement. This includes (not exhaustive):

  • Type parsing (date, boolean, etc.)
  • All kinds of parameters (query, headers, etc.)
  • Autorest extensions (x-ms-skip-url-encode, etc.)
  • Paging protocol
  • LRO protocol

The testserver has a coverage system that will count the numbers of calls you did that are correct, and expected. You can export this report from a special endpoint /report exposed. This report is used for coverage report in the following page: http://azure.github.io/autorest/dashboard.html

The basics

Starting the server

The testserver is implemented in NodeJS, this means the simple usage is:

git clone https://github.com/Azure/autorest.testserver.git
cd autorest.testserver
npm install
npm start

The usual way to start it part of your test, is to make it a dev dependency and start it from "node_modules". See for instance the package.json of autorest.python.

By default the testserver is starting on port 3000, but you can set the env variable PORT

Generating the clients

The testserver comes with a set of Swagger that you should used to generate your clients. If you install the testserver as a dev dependency, they can be found in node_modules\@microsoft.azure\autorest.testserver\swagger

There is no special flags to use for those Swaggers, but the following ones should be generated using the azure-arm:true flag:

  • head.json
  • head-exceptions.json
  • lro.json
  • subscriptionId-apiVersion.json
  • paging.json
  • custom-baseUrl-paging.json
  • azure-special-properties.json

Writing tests

When you write your tests using the generated clients. Usually, one operation is tight to one test, and calling all the generated operations across all the tests means you reach 100% coverage. There is some exceptions, where you might have to call the same operation several times with different parameter.

There is no documentation for what each test is supposed to do, the best way to inder the behavior is to look at tests from already existing autorest, or to read the testserver code: https://github.com/Azure/autorest.testserver/tree/master/legacy/routes https://github.com/Azure/autorest.python/tree/autorestv3/test/vanilla/AcceptanceTests

Clone this wiki locally