The main way of testing niri during development is running it as a nested window. The second step is usually switching to a different TTY and running niri there.

Once a feature or fix is reasonably complete, you generally want to run a local build as your main compositor for proper testing. The easiest way to do that is to install niri normally (from a distro package for example), then overwrite the binary withsudo cp ./target/release/niri /usr/bin/niri. Do make sure that you know how to revert to a working version in case everything breaks though.

If you use an RPM-based distro, you can generate an RPM package for a local build withcargo generate-rpm.

Niri usestracing for logging. This is how logging levels are used:

• error!: programming errors and bugs that are recoverable. Things you'd normally useunwrap() for. However, when a Wayland compositor crashes, it brings down the entire session, so it's better to recover and log anerror! whenever reasonable. If you see anERROR in the niri log, that always indicates abug.
• warn!: something bad but stillpossible happened. Informing the user that they did something wrong, or that their hardware did something weird, falls into this category. For example, config parsing errors should be indicated with awarn!.
• info!: the most important messages related to normal operation. Running niri withRUST_LOG=niri=info should not make the user want to disable logging altogether.
• debug!: less important messages related to normal operation. Running niri withdebug! messages hidden should not negatively impact the UX.
• trace!: everything that can be useful for debugging but is otherwise too spammy or performance intensive.trace! messages arecompiled out of release builds.

We have some unit tests, most prominently for the layout code and for config parsing.

When adding new operations to the layout, add them to theOp enum at the bottom ofsrc/layout/mod.rs (this will automatically include it in the randomized tests), and if applicable to theevery_op arrays below.

When adding new config options, include them in the config parsing test.

Make sure to runcargo test --all to run tests from sub-crates too.

Some tests are a bit too slow to run normally, like the randomized tests of the layout code, so they are normally skipped. Set theRUN_SLOW_TESTS variable to run them:

env RUN_SLOW_TESTS=1 cargo test --all

It also usually helps to run the randomized tests for a longer period, so that they can explore more inputs. You can control this with environment variables. This is how I usually run tests before pushing:

env RUN_SLOW_TESTS=1 PROPTEST_CASES=200000 PROPTEST_MAX_GLOBAL_REJECTS=200000 RUST_BACKTRACE=1 cargo test --release --all

Theniri-visual-tests sub-crate is a GTK application that runs hard-coded test cases so that you can visually check that they look right. It uses mock windows with the real layout and rendering code. It is especially helpful when working on animations.

We have integration with theTracy profiler which you can enable by building niri with a feature flag:

cargo build --release --features=profile-with-tracy-ondemand

Then you can open Tracy (you will need the latest stable release) and attach to a running niri instance to collect profiling data. Profiling data is collected "on demand"—that is, only when Tracy is connected. You can run a niri build like this as your main compositor if you'd like.

cargo build --release --features=profile-with-tracy

To make a niri function show up in Tracy, instrument it like this:

pubfnsome_function(){let _span = tracy_client::span!("some_function");// Code of the function.}

You can also enable Rust memory allocation profiling with--features=profile-with-tracy-allocations.