Test your plugin

A plugin has several separate test boundaries: its own logic, SDK messages, package completeness, permission/compatibility behavior and the real phone/helper action. Pick a check that exercises the boundary you are trying to validate.

Test the SDK and your implementation

go -C deck-plugins test ./...
python3 -m unittest discover -s deck-plugins/sdk/python/tests -v
python3 -m unittest discover -s capabilities/tests -p test_contracts.py -v

Test your own action logic separately from the SDK. For cross-language transport fixtures, install a C++17 compiler, JDK and Gson, then run python3 -m unittest discover -s capabilities/tests -v with GSON_JAR set.

Verify installed tutorial packages

python3 tools/test_packaged_examples.py   deck-plugins/dist/examples/go/com.example.echo.deckPlugin   deck-plugins/dist/examples/python/com.example.echo.deckPlugin   deck-plugins/dist/examples/java/com.example.echo.deckPlugin   deck-plugins/dist/examples/cpp/com.example.echo.deckPlugin

This exercises catalog, successful invocation, unknown-action errors and correlation from a fresh extracted directory. It clears PYTHONPATH and CLASSPATH so a developer's environment cannot mask missing dependencies. It plays a brief beep for each implementation.

Release checklist

• Install the package on a clean test profile with the required runtime.
• Verify the catalog, add the button on Android, save and tap it.
• Verify success, invalid input, unavailable dependencies and failed external operations.
• For broker capabilities, test permission denial and revocation, compatible and incompatible providers, and unavailable OS features.
• Test helper restart, plugin crash, disable/remove and reinstall.
• Test an upgrade with the same plugin ID and saved deck actions.
• Verify every OS/architecture you claim, including the Windows helper rather than only a cross-compilation.
• Inspect the archive for missing resources, secrets, personal config and unexpected binaries.

The currently documented example packaging was executed on macOS. Windows-specific launchers and commands are supplied for verification; compilation on another OS does not certify Windows execution.

Test a generated starter

python3 tools/plugin.py test my-first-plugin

This uses the project's configured action. It extracts the package outside the checkout and verifies catalog, success and an unknown-action error. It does not press a phone UI button or validate an external player.

Test your action logic

Separate pure validation/decision logic from OS/service adapters. Unit-test required fields, supported actions, rejected input, dependency errors and successful behavior. Mock an external boundary when testing logic; separately execute the real adapter before release.

Capability-specific scenarios

Exercise missing grants, revoked grants, incompatible version ranges, provider removal, cancellation/timeout, malformed request values, state-topic updates and cleanup. A passing catalog check does not establish that your permission-controlled action is authorized.

Platform and lifecycle scenarios

Verify a clean install, update over an older release, saved buttons, user config, helper restart, plugin process exit/crash, disconnect/reconnect and disable/remove/reinstall. Test each OS/architecture you list in a release.

For high-impact actions, check duplicate invocation/retry behavior. For shared state, use the language's concurrency/race checks where available. For polling/subscriptions, measure resource use during idle, active use and reconnect rather than testing only one click.

Evidence to retain

Record the source/SDK revision, package version, OS/architecture, toolchain/runtime versions, command, exit code and relevant logs. Keep logs redacted. Distinguish compiled, simulated, isolated-package and real-device verification instead of presenting them as equivalent evidence.