Test a plugin

Test the plugin logic without a desktop session, then validate the manifest, every view tree and the release catalog.

Test plugin behavior

Use focused package tests while changing a plugin:

go test ./plugins/<dir>
go test ./cmd/sysc-plugin-<name>

Cover the data and error cases your plugin handles. Test handshake failures, host call errors, settings updates, view open/close and shutdown when those paths apply. Check that one view's failure does not corrupt other views.

Add a geometry test for each view the plugin can return. Run v1.Validate for structural rules and lint.Tree at the host dimensions. Use manifest dimensions for panels and the SDK constants for bars and tooltips.

Run repository checks

Before a pull request, run the relevant repository targets:

make test
make vet
make validate
make thumbnails
make catalog-validate

At the recorded sysc-plugins source, CI also runs gofmt, staticcheck, race-enabled tests, and make build STRICT=1. The strict build includes Calendar, which needs libecal2.0-dev and a native runner for each target architecture.

Capture fixture data

Every new catalog plugin needs screenshot.png and thumbnail.webp. The capture test must use fictional data. Never include real accounts, messages, hostnames, paths or device names in a committed fixture.

Install the preview command from the current shell source recorded on the source page, then capture one plugin:

go install github.com/Nomadcxx/sysc-shell/cmd/sysc-panel-preview@v0.1.1-0.20261009080304-0b6840392e1e
make capture PLUGIN=<dir>

The capture uses the plugin's real panel builder and manifest dimensions. A bar-only plugin can use a bar crop. Recreate both files after a visual change, then run make thumbnails to check the generated thumbnail.

For current capture and CI details, see the sysc-plugins publishing guide.