Conformance Kit

The suite every connector passes before review — what "passes the kit" means, how it runs, how a rule fails, the report it returns, and the twenty-three rules grouped by what they check.

"Passes the kit" means one thing everywhere: the same Subscriby\Connector\Testing\Conformance\ConformanceSuite runs against the first-party connectors and the SDK's fake inside Subscriby's own test suite, and against your package during review. It is what marketplace review starts from, and the reference every connector is measured against.

How it runs

use Subscriby\Connector\Contracts\ConnectorRegistry;
use Subscriby\Connector\Testing\Conformance\ConformanceSuite;

$report = (new ConformanceSuite(app(ConnectorRegistry::class)))
    ->run('example', packagePath: '/path/to/the/package');

The suite reads the connector and its ports from the application's registry, so the connector's service provider must have booted. Passing the package path adds the two rules that read files on disk (manifest.file_is_the_source, migrations.own_tables_only); without it they are skipped.

Every rule is guarded: a port that throws fails its own rule with the exception's class and message ("threw RuntimeException: …") while the rest of the kit still runs. An author fixing three things at once sees all three.

The report

ConformanceReport is all-or-nothing: one failed rule fails the connector, and each failure carries enough detail to be fixed without re-running anything by hand.

MemberMeaning
$report->connectorThe key.
$report->checksEvery ConformanceCheck in the order the kit ran them: name, passed, detail.
$report->passed()True when every rule held.
$report->failures()The checks that did not hold.
$report->summary()One line when green (example passes the conformance kit (23 checks).), otherwise one line per failure: example: settings.install_fields — install fields: "token" has no label.

A rule with several offenders lists them all in one detail, prefixed by what the list is ("install fields:", "links must be https URLs or mailto addresses:").

The rules

Fourteen rules run for every connector; the rest run when the connector binds the port they check; two read the package on disk.

GroupRules
Manifest rulesmanifest.key_matches, manifest.sdk_constraint, manifest.listing_links, manifest.resource_kinds, manifest.file_is_the_source (on disk)
Ports and formsports.required_bound, settings.install_fields, settings.settings_fields
Rendering and failurestext.plain_text_survives, text.canonical_sample_renders, failures.classifies_anything
Inbound, identity and slotsinbound.tolerates_empty_request, identity.tolerates_empty_envelope, identity.answers_reachability, slots.well_formed
Capability rulesaccess.declares_kinds, management.commands_match_manifest, relay.modes_match_manifest, recovery.vocabulary_and_readiness, portal_login.button, payments.provider_keys
Migration rulesmigrations.own_tables_only (on disk)

Where it runs

The suite needs a ConnectorRegistry. Inside Subscriby the application's registry is bound, so the kit runs on the first-party connectors and the fake in every test run, and on your package when Subscriby reviews it. In your own suite, the SDK's Subscriby\Connector\Testing\TestRegistry is that registry: register your manifest and connector into it and hand it to the suite, and it accepts or refuses the connector exactly as the application's registry does at boot, through the same PortAgreement, so no Subscriby checkout is needed to pass the kit. Testing a connector shows the test, and the fakes you write the rest of your tests against.

The kit is the floor

Passing it is the entry ticket. Beyond the kit lists what Subscriby's own suite checks that the kit cannot from outside, and Listing and Review what a reviewer reads for.

How is this guide?

On this page

Subscriby is a product designed by you — for you.

No boardroom full of executives deciding what we ships next. Our roadmap always shaped by you with your feedback.

Share feedback or a request