Struct lava_api_mock::LavaMock

source · [−]

pub struct LavaMock { /* private fields */ }

Expand description

A mock server that provides access to a SharedState.

This provides the following endpoints from the v0.2 Lava REST API:

/api/v0.2/aliases/
/api/v0.2/devices/
/api/v0.2/devicetypes/
/api/v0.2/jobs/
/api/v0.2/tags/
/api/v0.2/workers/

It also provides the following nested endpoints for jobs:

/api/v0.2/jobs/<id>/tests/
/api/v0.2/jobs/<id>/suites/

You can use uri to find the initial portion of the URL for your test instance.

The mock object does not support the Lava mutation endpoints, but you can mutate the provided SharedState directly for testing. There are two ways to do this:

You can keep a clone of the SharedState you pass in and obtain a MutateGuard with mutate.
You can call state_mut to get a MutateGuard for the enclosed SharedState directly.

Implementations

source

impl LavaMock

source

pub async fn new(p: SharedState, limits: PaginationLimits) -> LavaMock

Create and start a new LavaMock

Here p is the SharedState becomes the underlying data source for the mock, and limits are the default pagination limits as a PaginationLimits object, which are applied when the client does not give any.

source

pub async fn start() -> Self

Create and start a default new LavaMock.

This mock will have a default SharedState and default PaginationLimits. This gives a mock object with an empty data store, and no default pagination (so if the client does not request pagination, all matching data will be returned).

source

pub fn uri(&self) -> String

Return the URI of the server.

This object is based on a wiremock server, and as such it will usually be bound to an ephemeral port.

source

pub fn state(&self) -> Arc<State>

Read a read-only view of the current state of the data store.

Note that the data store is not currently prevented from evolving while this snapshot is held, because the underlying synchronisation mechanism is a CloneReplace.

source

pub fn state_mut(&mut self) -> MutateGuard<State>

Read a mutable view of the current state of the data store.

Note that the data store is not currently prevented from evolving while this snapshot is held, because the underlying synchronisation mechanism is a CloneReplace. Other writers are not prevented from acting on the data store, and their changes will be lost when this guard is flushed. Note that changes from a MutateGuard only take effect when the guard is dropped.