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(port: u16) -> 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 a signal, whatever the builder was told of these, see ServerBuilder::stop_on_signal. 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 and wait for its devices to be deleted, giving back the first error met deleting one, see ServerHandle::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 a server it serves is not when told so, 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, which a server it serves only does not when told so, 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.