Struct TestContext 

pub struct TestContext { /* private fields */ }

Servers run for a test, and what they are reached through, which is what pytango’s MultiDeviceTestContext is.

A context serves a database of its own, see TestDatabase, which is filled through Self::database as a real one is, then the servers registered in it, each on a port the system picks, see Self::serve, whose devices are then found through that database as a client of a real one finds them, see Self::dev.

let ctx = TestContext::new()?;
ctx.database().add_server("Motor/test", &[("test/motor/1", "Motor")])?;
ctx.serve(ServerBuilder::new("Motor", "test").class(ClassDef::<()>::new_default("Motor")))?;
ctx.dev("test/motor/1").ping()?;

Everything is served for real, through the default backend: the database and the devices are reached by any process, at Self::host and Self::port for the database, and by this one directly, as every device this process serves, see Self::is_local. Any implementation of a device can also be served on its own, see Self::serve_dev.

Everything it serves is dropped with it, with no side effect: a server that is to be stopped properly, its devices deleted, is stopped through the context, see Self::stop.

Implementations

impl TestContext

pub fn new() -> Result<Self>

A context serving an empty database, on a port the system picks.

pub fn with_port<R: RangeBounds<u16>>(port: R) -> Result<Self>

A context serving an empty database on that port, one the system picks if 0, which is what a database that clients are told of in advance needs.

pub fn host(&self) -> &str

The host the database answers at.

pub fn port(&self) -> u16

The port the database answers at.

pub fn database(&self) -> &DatabaseProxy

The database of this context, which is where the servers are registered before being served, with DatabaseProxy::add_server, and their properties set.

pub fn test_database(&self) -> &Arc<TestDatabase>

The database itself, which tells what it was asked and is made to fail, see TestDatabase.

pub fn serve(&self, builder: ServerBuilder) -> Result<Arc<Server>>

Serve that server until it is stopped, see Self::stop, or this context is dropped: it is served through the backend of this context, registered in its database, and listens on this machine only, on a port the system picks, and is never stopped on termination, whatever the builder was told of it, see ServerBuilder::stop_on_terminate. Its devices are then reached with Self::dev.

The server given back is shared with the context, which keeps owning it: it is dropped all the same when the context is.

pub fn server(&self, name: &str) -> Option<Arc<Server>>

The server of that exe/inst name this context serves, if it does.

pub fn stop(&self, name: &str) -> Result<()>

Stop the server of that exe/inst name, which deletes its devices, giving back the first error met, see Server::stop_async, and wait for it to be through, see Server::wait. A server that stopped on its own is only waited for.

The server stays with the context, stopped, until it is dropped.

pub fn serve_dev(&self, dev: Arc<dyn BackendDev>) -> Result<()>

Serve that device, under the name it gives, until this context is dropped, through the backend of this context, and export it in its database, which is where Self::dev then finds it: any implementation of a device is tested that way, a client of it above all, without any server around it.

The device must be defined in the database first, with DatabaseProxy::add_dev, as a real database refuses to export a device it does not know. A device served again under the same name replaces the one that was.

pub fn dev(&self, name: &str) -> DevProxy

A proxy to the device of that name, found through the database of this context.

pub fn is_local(&self, name: &str) -> Result<bool>

Whether the device of that name, as the database exports it, is reached directly by this process, which it is when this process serves it, unless its server was built with local(false), see ServerBuilder::local: it is then reached through the backend, as another process reaches it.

pub fn backend_dev(&self, name: &str) -> Result<Arc<dyn BackendDev>>

The device of that name, as the database exports it, reached as a client of this process reaches it: directly if this process serves it, see Self::is_local, unless its server was built with local(false), see ServerBuilder::local, and through the backend otherwise.

Trait Implementations

impl Debug for TestContext

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Drop for TestContext

fn drop(&mut self)

Drop every server, then every device, then the database, with no side effect: whatever was in flight is never answered, see BackendServer.

fn pin_drop(self: Pin<&mut Self>)

🔬This is a nightly-only experimental API. (pin_ergonomics)

Execute the destructor for this type, but different to Drop::drop, it requires self to be pinned.