Testing and debugging

Test the behavior your plugin owns using a mock PluginAPI. Core tests cover permission enforcement and host rendering; plugin tests should not import private host helpers.

Unit-test useful scenarios

Cover valid and invalid input, dialog cancellation, service rejection, changed settings, repeated enable/disable, and asynchronous completion after stop. Verify that disposers run and that a cancelled action cannot send a message or open an external page.

For storage migrations, test old data, missing data, invalid data, and repeated migration. For selectors, verify both the expected target and a missing target.

Try the packaged artifact

1. Build and pack your plugin.
2. Import the ZIP in Fluxer.
3. Review and enable the exact hash.
4. Exercise the feature, disable it, and confirm its UI/resources disappear.
5. Import an updated build and check that compatible settings survive while trust is reset.
6. Test small windows and light/dark Fluxer themes.

Manual actions in a real client can have real effects. Automated tests must mock message sending and external navigation or use the controlled fixture.

Diagnose a failed start

Check API version, matching identity, built-entry hash, and capability declarations first. Use api.logger with concise fields that omit secrets, paths, signed URLs, and private content.

Direct fetch, parent DOM access, or blocked image URLs indicate unsupported operations, not missing sandbox escape code.

The repository’s pnpm test:external-plugin builds and exercises the standalone starter outside the workspace using a generated Electron fixture. See contributor tests for prerequisites.