wlcs aspires to be a protocol-conformance-verifying test suite usable by Wayland compositor implementors.
It is growing out of porting the existing Weston test suite to be run in Mir's test suite, but it is designed to be usable by any compositor.
There have been a number of previous attempts at a Wayland compositor test suite - the Wayland Functional Integration Test Suite, and the Weston test suite are a couple of examples.
What sets wlcs apart from the graveyard of existing test suites is its integration method.
Previous test suites have used a Wayland protocol extension to interrogate the compositor state. This obviously requires that compositors implement that protocol, means that tests only have access to information provided by that protocol, and the IPC means that there isn't a canonical happens-before ordering available.
Instead, wlcs relies on compositors providing an integration module, providing wlcs with API hooks to start a compositor, connect a client, move a window, and so on. This makes both writing and debugging tests easier -the tests are (generally) in the same address space as the compositor, so there is a consistent global clock available, it's easier to poke around in compositor internals, and standard debugging tools can follow control flow from the test client to the compositor and back again.
In order for wlcs to test your compositor you need to provide an integration module. This needs to implement the interfaces found in include/wlcs. If your integration module is awesome_compositor_wlcs_integration.so, then running wlcs awesome_compositor_wlcs_integration.so will load and run all the tests.
wlcs requires a small number of hooks into your compositor to drive the tests - it needs to know how to start and stop the mainloop, to get an fd to connect a client to, and so on.
To access these hooks, wlcs looks for a symbol wlcs_server_integration of type struct WlcsServerIntegration const (defined in include/wlcs/display_server.h) in your integration module.