# Testing with libtmux

Source: https://libtmux.org/en/rs/latest/guides/testing-with-libtmux/

> Use an isolated server and check cleanup failures.

The `test-support` feature exposes [`TestServer`](<https://libtmux.org/en/rs/latest/reference/test-testserver/>) and asynchronous wait helpers.
[`TestServer`](<https://libtmux.org/en/rs/latest/reference/test-testserver/>) is acceptable in examples for now. Application examples will move
to the regular [`Server`](https://libtmux.org/en/rs/latest/reference/server-server/) object. The complete
capture program already uses [`Server::builder`](<https://libtmux.org/en/rs/latest/reference/server-server-builder/>) with an explicit private socket
and performs its own shutdown.

## Run a complete example

[Capture pane output](https://libtmux.org/en/rs/latest/examples/capture-pane-output/) includes a complete
Rust executable, imports, dependency setup and cleanup. Its output check fails
when the expected line does not arrive before the deadline. Start with that
program when adapting the pattern to your own test runner.

## Keep server ownership explicit

Give each test a private socket and a known tmux configuration. Stop the server
the test creates, including when startup or an assertion fails. Preserve the
original failure and report cleanup errors so a leaked server remains visible.

A connection to an existing server has a different lifetime. The
[attach program](https://libtmux.org/en/rs/latest/guides/attaching-to-tmux/) leaves that server running and lets its
launcher own cleanup.

## Wait for the state you assert

Wait for the actual output or completion condition with a deadline.
[Sending keys](https://libtmux.org/en/rs/latest/guides/sending-keys/) returning successfully does not establish
that the application finished. [Capturing output](https://libtmux.org/en/rs/latest/guides/capturing-output/) explains
the difference between a screen snapshot and a stream of output.