MikrotikApi.Transport.Mock (mikrotik_api v0.3.4)

View Source

In-memory transport for tests that need to mock MikroTik RouterOS REST endpoints.

This module is part of the public testing API. It lets downstream projects test code that calls MikrotikApi without running a RouterOS device or opening a network connection.

Configure it in your test setup:

Application.put_env(:mikrotik_api, :transport, MikrotikApi.Transport.Mock)

Then stub RouterOS paths for the current test process:

MikrotikApi.Transport.Mock.stub(:get, "/system/resource", 200, %{"uptime" => "1h"})

Stubs are isolated by process. For code that calls the API from another process, pass owner_pid: self() to the MikroTik API call so the worker process can use the test process' stubs.

For lower-level assertions, use put/1 with a five-arity function matching the MikrotikApi.Transport callback arguments.

Stub Matching

stub/5 matches on the HTTP method and RouterOS path only. Host, port, scheme, query parameters, headers, and body are intentionally ignored. Use put/1 when a test needs to assert on those request details.

Response Bodies

Map and list bodies are encoded with JSON.encode!/1; binary bodies are returned as-is; nil is returned as an empty response body.

Summary

Types

handler()

Low-level mock handler.

method()

HTTP method supported by the MikroTik REST client.

response()

Mock response in the same shape returned by MikrotikApi.Transport.request/5.

Functions

clear()

Clears mocks for the current process.

clear(owner)

Clears mocks for a specific owner process.

put(fun)

Installs a low-level request handler for the current process.

stub(method, path, status, body \\ nil, headers \\ [])

Stubs a RouterOS REST path for the current process.

Types

handler()

@type handler() :: (method(),
              MikrotikApi.Transport.url(),
              MikrotikApi.Transport.headers(),
              MikrotikApi.Transport.body(),
              keyword() ->
                response())

Low-level mock handler.

The arguments are method, full URL, request headers, request body, and transport options.

method()

@type method() :: MikrotikApi.Transport.method()

HTTP method supported by the MikroTik REST client.

response()

@type response() ::
  {:ok, {pos_integer(), [{charlist(), charlist()}], binary()}}
  | {:error, term()}

Mock response in the same shape returned by MikrotikApi.Transport.request/5.

Functions

clear()

@spec clear() :: :ok

Clears mocks for the current process.

Call this from test setup when using async tests to avoid stale stubs if a test process is reused.

clear(owner)

@spec clear(pid()) :: :ok

Clears mocks for a specific owner process.

This is useful when a test installed stubs for a known owner process and cleanup happens from another process.

put(fun)

@spec put(handler()) :: :ok

Installs a low-level request handler for the current process.

The handler receives method, url, headers, body, and transport opts. Use this when a test needs to assert on the exact URL, authorization header, request body, or HTTP options.

The handler must return either {:ok, {status, headers, body}} or {:error, reason}.

A low-level handler takes precedence over any stubs installed with stub/5 for the same process.

stub(method, path, status, body \\ nil, headers \\ [])

@spec stub(method(), String.t(), pos_integer(), binary() | map() | list() | nil, [
  {charlist(), charlist()}
]) :: :ok

Stubs a RouterOS REST path for the current process.

path should be the RouterOS path without the /rest prefix, for example "/system/resource" or "/ip/address".

The stub is selected by {method, path}. For example:

Mock.stub(:get, "/system/resource", 200, %{"uptime" => "1h"})
Mock.stub(:put, "/ip/address", 201, nil)

body can be:

  • a map or list, encoded as JSON
  • a binary, returned unchanged
  • nil, returned as an empty body

headers are response headers and should use the same charlist tuple shape as the transport behaviour, for example {~c"content-type", ~c"application/json"}.